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 >postgresql. > > > 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 connection.
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 >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 > > ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org