Re: Persistent connections and transactions

From: Date: Sat, 27 Jan 2001 06:18:45 +0000
Subject: Re: Persistent connections and transactions
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-36960@lists.php.net to get a copy of this message
on 1/25/01 11:49 AM, Frank Joerdens at frank@joerdens.de wrote: > On Thu, Jan 25, 2001 at 04:04:24PM -0300, Martin A. Marques wrote: > [ . . . ] >> Of course. But the persistent connection are not working as the manuals say >> they should work. > It appears this riddle has been solved: From a post by Adam Lang on > pgsql-php on Dec 8: > <start quote> > Well, there's a problem with PHP's [mis]documentation. First of all, > it counts open DB connections not on per-webserver, but on > per-process/thread basis. > The default PHP config file has the limits of persistent and > non-persistent connections set to -1 (no limit)... Setting it to > some (supposedly) reasonable value (like, 50) accomplishes nothing: you > should multiply 50 by the number of webserver processes/threads. There > can be lots of them... :[ > And then there comes PHP's "logic": if I can just open the new > connection, why bother reusing the old one? And thus Postgres backends > start multiplying like rabbits, eventually reaching the limit... :[ > You should set a reasonable limit on number of open persistent > connections (like 1, maybe 2 or 3), only then PHP will actually reuse > them. My webserver now works with such setup and there are no more > problems with pg_pconnect(). > <end quote> This sounds very confusing. Does anyone know how pconnects are pooled? For instance this post implies that pconnects might be pooled on a per httpd child process which would be silly as hell because httpd processes surely "spawn like rabbits" and all of them would eventually cycle to a web page that would generate a persistant connection. How are pconnects released into the pool? If the former case there is no pool so no reason to release. In the latter case, there should be a procedure I could call (like pg_pclose()?) which would not close the connection but simply release it back into a pool for another pconnect() of a different httpd to call. This could especially be useful for long-running scripts. How are pconnects terminated? Is there a time to live on them? Are they never dying unless the child dies? The load on most web servers often varys by a factor of 8 during the day and 2 between weekends and weekdays. Without pconnect termination, one would accumulate a lot of idle persistent connections. Ideally, PHP would manage it. It's not like the pconnect() HAS to be on a per-child business. In theory pconnects could be put into a shared memory segment and pooled. A time to live of 30 minutes and configurable in php.ini would handle most web server/db interaction and ensure that you don't have say 115 open connections to the database with only 4 being used at a time. I don't know how PHP is programmed or how the PosgreSQL extension was made so I really have no clue here. terry -- terry chay, Director of Engineering, <http://www.QIXO.com/> QIXO /kick.so/ - Integrating Many Travel Web Sites Into One W: 1.408.394-8102 F:1.408.516.9090 M: 1.408.314.0717 E-Mail: <mailto:tychay@qixo.com> ICQ: 16069322 PGP Fingerprint: 6DCF 1634 547C 935D 4912 2A44 A4A2 79AB DFFF F110

« previous php.general (#36960) next »