[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: Confused Apache::DBI (best practice)
From:       Jonathan Vanasco <jvanasco () 2xlp ! com>
Date:       2007-07-17 19:27:06
Message-ID: EC61D35B-5CD9-4299-9609-00BA7268439A () 2xlp ! com
[Download RAW message or body]


On Jul 17, 2007, at 6:31 AM, Clinton Gormley wrote:
> You should not share connections between processes.  You will end up
> with segfaults.

Thats a 'best case scenario'.  More typically, you'll just have a ton  
of transactional issues and not have any integrity on your database  
of app/db logic.




> On 7/17/07, Clinton Gormley <clint@traveljury.com> 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.

Seconded.   can you even run 150?  i've got 4gb on mine, and we max  
out at 20.  sure, we can spawn 150, but after 20 there hasn't been  
any added benefit ( law of diminishing marginal utility ) and after  
30 we ran into memory issues ( as memory unshares, you can run less  
processes ).  we found 20 ideal for our current setup.  your milage  
may vary (and ours has as the codebase is tweaked )

> 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'll second sqlrelay.  its great.


> 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.

pooling connections can also be useful if you segment db connections  
and transactions within a request cycle.  ie: if you only need to  
read a single table on an early phase , you should be able to pool 2  
connections for 10 children , as any wait time will be offset by db  
blocking in later request cycles of your app.  thats theoretical  
though, i haven't had the need/time to try that, but i'm convinced it  
will work!



// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -
|   CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -
|     Founder/CTO/CVO
|      FindMeOn.com - The cure for Multiple Web Personality Disorder
|      Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -
|      RoadSound.com - Tools For Bands, Stuff For Fans
|      Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -


[prev in list] [next in list] [prev in thread] [next in thread]