On Sat, 17 May 2003, David Busby wrote: > List, > I cannot tell from the documentation if pg_pconnect() or pg_connect() > are really different in how the connection pool is managed. Does anyone > know if that is the case? Seems that using pg_pconnect would dictate "use a > pooled connection" and pg_connect is "use a pooled connection, or make a new > one". On "live" apps which is better to use, seems pg_pconnect. Thoughts? This is a far more complex subject than it may at first appear. The first and most important point is that PHP doesn't "pool" connections when using persistant connections. what happens is that each apache child preocess holds a connection open after a pconnect has been used. this means that using the default apache configuration option of 150 max children, and the postgresql default of 32, that after a little bit of load is applied, your whole web site comes crashing with errors about no more backend connections available. I.e. using pconnect without understand the implications, and configuring your web site accordingly, is dangerous. pconnects in PHP are like tiny ints in mysql, I consider them to almost be a misfeature, in that they are so often used by folks who don't know what they're getting themselves into. pconnects don't save much time. My testing showed them to be 1,000 times faster than regular connects. Unfortunately, since regular connects run in about 1 mS, having persistant connects run at 1 uS doesn't really help. I.e. the average PHP page takes 10 to 100 mS to run, so chopping off <1 mS from the connect speed is pretty much noise for most folks. Another issue is that if you use pconnect to two different databases in the same cluster in a PHP script, you now have TWO persistant connections open at the same. Open to three databases, three persistant connections. IF you want to use pconnects, then you need to do some system planning and configuration. If you are running multiple front end apache servers, they need to be configured so that you have fewer connects open than the max that postgresql can handle at any given time. So, set max children lower in apache (20 to 50 or so) and multiply the max number of different connects in each script, times the number of apache servers, add a 10 or 20 for overhead, and set the postgresql max connects to that. Otherwise, your site will have issues with connecting. And that would make it WAY slower than just using plain old connect.
