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. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
