Oh, sorry pal, I were convinced that the child process were destroyed after the keepalived connection has died. In fact what happens with apache is (if I have understand correctly) : - The apache child process (pid 8888) is created with "Client A" connected on it. - if "Client A" don't query the server for 15 secondes (keepalive timeout), "Client A" is disconnected from the apache child process, pid 8888. BUT the apache child process 8888 is still alive waiting for connections ? - If "client A" had launched a script using a pconnect() call, a connection has been created beetween a pgsql process and process 8888. - a new client "Client B" now connects itself to apache process 8888 (why this process and not another living idling apache process ? :)), I guess any similar pconnect will use the already existing pgsql connection. I wish I'm right ! Thx in advance. Sylvain. -----Message d'origine----- De : pgsql-php-owner@xxxxxxxxxxxxxx [mailto:pgsql-php-owner@xxxxxxxxxxxxxx]De la part de scott.marlowe Envoye : lundi 15 decembre 2003 22:55 A : Sylvain Ross Cc : pgsql-php@xxxxxxxxxxxxxx Objet : Re: [PHP] What is wrong with pg_pconnect() ? As Rod pointed out, you likely aren't having dead apache children, just too many. IF you must have pconnects in your code, then you need to configure your apache server and postgresql server so that the postgresql server can spawn more children than the apache server. Set MaxClients in httpd.conf to something MUCH lower than the default of 150. Usually 20 to 50 will be plenty. Restart apache. Then, set postgresql to handle at least 2x as many backends as with the max_connections setting and restart it. Now, you should be able to handle pconnects. My personal testing has shown my dual PIII-750 (being retired at the end of the month) can handle about 1,000 to 10,000 pg_connects a second, and about 100,000 to 1,000,000 pg_pconnects a second. Since the average page build / delivery time on our intranet server is around 0.5 to 1.5 seconds, the speed of connections is pretty much noise. We have templating, database accesses, and httpd authentication via LDAP on each page, and the biggest eater of CPU time is the httpd->LDAP authentication, followed by the templating, followed by the database layer. I.e. Postgresql and its connections are the least of our worries. :-0 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
