on 1/25/01 11:49 AM, Frank Joerdens at [EMAIL PROTECTED] 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:[EMAIL PROTECTED]> ICQ: 16069322
PGP Fingerprint: 6DCF 1634 547C 935D 4912 2A44 A4A2 79AB DFFF F110
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
