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 

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

Reply via email to