On Tue, 2007-07-17 at 12:36 +0100, Anthony Gardner wrote: > Yes, I'm aware of all of that, but it's the 'you will only have one > connection per apache child'. So with 150 processes, that's 150 > connections / DB instance. No?!
Correct > > And the 'Oracle can handle this with ease.' Oracle can handle what > with ease? The number of DB connections allowed is determined by the > DB adminstrator based on resources available. So, it's all relative. That was probably a bit glib. What I really meant was that, given the number of real work-doing mod_perl processes that you can run on one box, the number of connections should not be your biggest issue. But yes, 150 connections may be a lot depending on your database. However, if you need 150 mod_perl children, then it is a busy site, and you need a database server big enough to support it. I don't have experience using Oracle for websites, so I'm not sure just how heavy each connection is, but I do know that the connection process is a lot heavier than (eg) for MySQL, so caching connections is a win with oracle. > But, the problem still remains, with 1 connection per process / 150 > processes == 150 connections. > > Is that it, end of story or are there more ways to manage this? Presumably, all 150 children are going to be working concurrently, in which case they all need database connections and so yes, you're stuck with that. If they won't all be busy at the same time, you could reduce the timeout on the connection, so idle connections are dropped. But in this case, it may perform better if you reduce the number of processes instead. There has been talk of using apache's mod_dbd to pool connections, but you would need to alter DBD::Oracle to support it. Also, you come back to the same issue: if you really need 150 mod_perl processes, then you probably need 150 DB connections. Don't know if anybody else has any better idea? One suggestion, which you probably won't like, is consider using a more light weight database, eg MySQL? It's well suited to websites, and performs very well. But not what you want to hear, I'm sure :) Clint
