scott.marlowe wrote:

>On Wed, 14 Jan 2004, Adam Alkins wrote:
>>scott.marlowe wrote:
>>>A few tips from an old PHP/Apache/Postgresql developer.
>>>1: Avoid pg_pconnect unless you are certain you have load tested the 
>>>system and it will behave properly.  pg_pconnect often creates as many 
>>>issues as it solves.
>>I share the above view. I've had little success with persistent 
>>connections. The cost of pg_connect is minimal, pg_pconnect is not a 
>>viable solution IMHO. Connections are rarely actually reused.
>I've found that for best performance with pg_pconnect, you need to 
>restrict the apache server to a small number of backends, say 40 or 50, 
>extend keep alive to 60 or so seconds, and use the same exact connection 
>string all over the place.  Also, set max.persistant.connections or 
>whatever it is in php.ini to 1 or 2.  Note that max.persistant.connections 
>is PER BACKEND, not total, in php.ini, so 1 or 2 should be enough for most 
>types of apps.  3 tops.  Then, setup postgresql for 200 connections, so 
>you'll never run out.  Tis better to waste a little shared memory and be 
>safe than it is to get the dreaded out of connections error from 
I disagree.   With the server I have been running for the last two years
we found the the pconnect settings with long keep-alives in apache
consumed far more resources than you would imagine.   We found the
because some clients would not support keep-alive (older IE clients)
correctly.  They would hammer the server with 20-30 individual requests;
apache would keep those processes in keep-alive mode.   When the number
of apache processes were restricted there were DoS problems.   The
short-keep alive pattern works best to keep a single pages related
requests to be served effeciently.   In fact the best performance and
the greatest capacity in real life was with a 3 second timeout for
keep-alive requests.   A modem connection normally won't have sufficient
lag as to time-out on related loads and definitely not a broadband

Also, depending on your machine you should time the amount of time it
takes to connect to the db.   This server ran about 3-4 milliseconds on
average to connect without pconnect, and it was better to conserve
memory so that none postgresql scripts and applications didn't have the
extra memory footprint of a postgresql connection preventing memory
exhaustion and excessive swapping.

Please keep in mind that this was on a dedicated server with apache and
postgresql and a slew of other processes running on the same machine.  
The results may be different for separate process oriented setups.

>If you do all of the above, pg_pconnect can work pretty well, on things 
>like dedicated app servers where only one thing is being done and it's 
>being done a lot.  On general purpose servers with 60 databases and 120 
>applications, it adds little, although extending the keep alive timeout 
>but if you just start using pg_pconnect without reconfiguring and then 
>testing, it's quite likely your site will topple over under load with out 
>of connection errors.
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to