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