On Thu, 31 Jan 2002, Frank Bax wrote: > At 12:11 PM 1/31/02 -0700, tom.kemp@xxxxxxxxxxx wrote: > >Also, if I do a persistent connection, it appears that PHP will try to > >use this connection if it exists, prior to creating a new persistent > >connection, right? Well, does it only reuse the already connected > >persistent if it is the same user? How does this work? Does it check > >that it is the same user/password (does my script have to supply this > >in the second persistent connection function) prior to using the > >preexisting connection? Is it tied to the current browser request? > > We've talked a lot about pg_pconnect this week; I'll try to summarise what > we've learned... > > Each browser request from client is handled by an apache child process on > server. Apache uses multiple child processes running concurrently to > handle these browser requests. > > pg_pconnect will reuse a previously created connection to the database if > the previous connection was made within the same apache child process *and* > the connect string is "identical" (same host, database, username, password). > http://www.php.net/manual/en/features.persistent-connections.php > Using pg_pconnect() over pg_connect() may not always be a huge saving. > Persistant connections are typically desired if your database server is a > separate box from your webserver. If these servers are in the same box, > and query execution time is dominate factor on your system, then there is > minimal saving with pg_pconnect over pg_connect. If you have simple, very > fast queries, then TCP connect and fork/exec (of the postgres backends) > overhead may dominate and pg_pconnect wins again. Of course, we're optimizing for time, here. pconnect has a BIG overhead: it increases the memory footprint of your application a lot. You see it on the host which is running postgresql, of course. So use pconnect() if you've got RAM to spare (and on a large DB server, RAM is never enough). What I mean here is that it's never a win, it's always a tradeoff. > If you support many different connect strings, then there is another factor > to consider. You should expect to see many postgres client connections > running on your server: > A) Number of unique connect strings used. > B) Number of active apache child processes. > > Multiply A*B to get max number of possible concurrent connections on your > system (max_connections in postgresql.conf). If A*B can go over postgres > connection limit, then you might start getting connection refused messages; > in which case you might consider pg_connect. Otherwise, you move security > code into your php scripts and use a single username for database access. > > Frank > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > .TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@xxxxxx
