El Jue 25 Ene 2001 16:49, Frank Joerdens escribió:
> 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>
Yes, I got this mail from Adam, but I think it was on the IMP mailing list or
the Postgres-devel mailing list. Well, that doesn't matter to much. ;-)
Any way, it speaks very bad about the logic that PHP has of what is a
persistent connection (I think I had the same problem with informix).
> > That has nothing to do with apache. If the SQL statments are well
> > implemented, the second query wouldn't see any of the changes that the
> > first query executed until the work is commited, and it shouldn't be able
> > to modify the rows with which the first query is updating or deleting.
> > But thats Postgres that doesn't let it, not the apache server, not php.
>
> You are assuming that the Postgres backend has accurate information
> about the client's identity. The "client" for the backend is the Apache
> child, not the browser. The Postgres backend doesn't know anything about
> web browsers. So if Apache/PHP allows a 2nd browser to connect to a
> particular Apache process while it's waiting for a query to complete
> that would generate information to be sent back to the first browser,
> then you're in trouble. But I think it would be pretty silly for
> Apache/PHP to allow that.
OK, lets see if we can understand what each other is saying (maybe I'm not
getting your point here).
Lets say browser A connects to the apache server, to a page using php code.
Lets say the code is OK (no bugs). Apache opens a persistent connection to
the database and starts executing the queries. Now the connection between the
apache server and the web browser doesn't close until the queries are all
finished and the output is send back to the browser.
Now, how about if browser B connects to the apache server just in the middle
of the execution of the queries that browser A asked for?
Well, the connection between Browser A and the web server is still opened, so
another httpd child process answers the request. If a persistent connection
is needed (as Adam said) this child will open a new one, because the other
one is still in use.
So now you have two web connections with two backend connections.
My question would be, and seeing Adams thoughts, wouldn't it be the best
optimization configuration of php.ini to have only one persistent conection?
Wouldn't there be one per-child? Any way, you can't have two connections to
the same httpd child.
Saludos... :-)
--
System Administration: It's a dirty job,
but someone told I had to do it.
-----------------------------------------------------------------
Martín Marqués email: [EMAIL PROTECTED]
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------
--
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]
