On 7/17/07, Clinton Gormley <[EMAIL PROTECTED]> wrote:
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.
Anthony, Clinton is right. I suspect you haven't done an assessment of how many mod_perl processes you can fit on your hardware. If each one took 50MB (very possible), you would need more than 7GB of RAM in your mod_perl machine to run 150 processes, or else a cluster with that much RAM. Here's some advice: Make sure you are using the same connection string at all times, so that you only get 1 connection per process. If there's any difference in the way you connect, Apache::DBI will open another connection, which you don't want. Use a reverse proxy, as described in the mod_perl docs. Then none of you database connection will be tied up by apache processes that don't need them. This usually results in about 10 times fewer database connections than if you just sent all requests straight to mod_perl. Read the performance tuning sections of the mod_perl docs about setting MaxClients. If you do these things and you still need more connections, Oracle does provide tools for pooling connections at the database server itself. You can ask your DBAs about them. Being Oracle DBAs, they will probably just say it doesn't work and refuse to try it, but it may be worth checking. You can also look at sqlrelay. I can tell you that I've run a couple of large sites on Oracle without needing to do anything special. It can handle a lot of load.
Presumably, all 150 children are going to be working concurrently, in which case they all need database connections
This is the key to remember. Pooling connections is only useful if you have open connections in processes that are sitting around doing nothing. That should not be the case if you tune your mod_perl as suggested above. - Perrin
