Re: [PHP] Persistent connections
On 25 Oct 2013, at 12:51, Nibin V M nibi...@gmail.com wrote: Thank you for the quick response Stuart...one more doubt..at http://php.net/manual/en/features.persistent-connections.php they states = This means that when the same client makes a second request to the server, it may be served by a different child process than the first time. When opening a persistent connection, every following page requesting SQL services can reuse the same established connection to the SQL server = Is the persistent connection pool is re-used between apache child processes ? No, connections are not shared between PHP processes. Nothing is shared between PHP processes. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ On Fri, Oct 25, 2013 at 3:54 PM, Stuart Dallas stu...@3ft9.com wrote: On 25 Oct 2013, at 11:10, Nibin V M nibi...@gmail.com wrote: I have been reading docs and many are telling that persistent connections are kept open indefinitely. But I found in PHP docs that it will not close after script execution like requesting a page; so should it close after the request is over? So when exactly a persistent connection should close? Please advice. A persistent connection is closed when the PHP process ends, or it gets disconnected by the server-side or due to a network error. Attempting to explicitly close a persistent connection will do nothing without complaining. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- Regards Nibin. http://TechsWare.in -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Persistent connections
Hello, I have been reading docs and many are telling that persistent connections are kept open indefinitely. But I found in PHP docs that it will not close after script execution like requesting a page; so should it close after the request is over? So when exactly a persistent connection should close? Please advice. -- Regards Nibin.
Re: [PHP] Persistent connections
On 25 Oct 2013, at 11:10, Nibin V M nibi...@gmail.com wrote: I have been reading docs and many are telling that persistent connections are kept open indefinitely. But I found in PHP docs that it will not close after script execution like requesting a page; so should it close after the request is over? So when exactly a persistent connection should close? Please advice. A persistent connection is closed when the PHP process ends, or it gets disconnected by the server-side or due to a network error. Attempting to explicitly close a persistent connection will do nothing without complaining. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Persistent connections with mysql_pconnect()
On Tuesday 25 March 2003 09:02 am, skate [EMAIL PROTECTED] wrote: leaving the connection open creates security questions, and also leaves resources open, what if a user closes his browser window, how do you know to close the connection? So are you saying that persistent connections [ i.e. mysql_pconnect() ] should never be used? if you really want to make it simple, you can edit your php.ini to have the username and password as default in there, but again, this can be a security risk. i'm afraid the best way is to include connection code on every page... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Persistent connections with mysql_pconnect()
no, not at all... but there is a time and a place, and i don't think you should use pconnect just because you don't want to an include at the top of every page. - Original Message - From: John Hicks [EMAIL PROTECTED] To: php [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 5:11 PM Subject: [PHP] Persistent connections with mysql_pconnect() On Tuesday 25 March 2003 09:02 am, skate [EMAIL PROTECTED] wrote: leaving the connection open creates security questions, and also leaves resources open, what if a user closes his browser window, how do you know to close the connection? So are you saying that persistent connections [ i.e. mysql_pconnect() ] should never be used? if you really want to make it simple, you can edit your php.ini to have the username and password as default in there, but again, this can be a security risk. i'm afraid the best way is to include connection code on every page... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Persistent connections with mysql_pconnect()
no, not at all... but there is a time and a place, and i don't think you should use pconnect just because you don't want to an include at the top of every page. You still have to call pconnect() on every page if you use it. It doesn't leave it open for other requests, it leaves it open within the web server program. pconnect() is only useful on certain OS using certain web servers. Read the manual page on mysql_pconnect() for more information. ---John Holmes... - Original Message - From: John Hicks [EMAIL PROTECTED] To: php [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 5:11 PM Subject: [PHP] Persistent connections with mysql_pconnect() On Tuesday 25 March 2003 09:02 am, skate [EMAIL PROTECTED] wrote: leaving the connection open creates security questions, and also leaves resources open, what if a user closes his browser window, how do you know to close the connection? So are you saying that persistent connections [ i.e. mysql_pconnect() ] should never be used? if you really want to make it simple, you can edit your php.ini to have the username and password as default in there, but again, this can be a security risk. i'm afraid the best way is to include connection code on every page... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] persistent connections
Lo all, Is there anyway to manage persistent connections to MySQL? I've started using them on various of my sites (mysql_pconnect instead of mysql_connect - as in the documentation), but after a few hours, I notice that the connections just keeps on getting more and more and more. Eventually, the entire server crawls to a standstill and I have to restart mysql to speed up the system... Any ideas? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Persistent connections and transactions
Frank Joerdens wrote: On Fri, Jan 26, 2001 at 11:01:14AM +, Nuno Silva wrote: [ . . . ] i ran across this transaction problem vs. persistent conn in pgsql some time ago. I found two workaround methods: - don't use persistent conn's :-) or; - start every conn with the usual pg_pconnect and then query a rollback to the server: $query="ROLLBACK work;" (this will kill any supposed transaction in ABORT STATE that some child had left). postgres don't support nested transactions (yet), but when it does maybe you should add multiple "ROLLBACK WORK;" queries :-) Ah. Very cool. What I _still_ don't quite understand, though, is _how_ exactly this situation could come about. And what the worst case would be. What if you don't kill the transaction in ABORT STATE? Ta, Frank Hi, this happens because pg_pconnect don't know about transactions. If some transaction reach ABORT and for some reason the script never makes it to COMMIT or ABORT queries the postgresql backend will be _always_ in ABORT STATE. The problem is present in several combinations... for instance: in mysql you could make the connection with one user to database X. While logged in you could change to database Y This database backend will be in database Y after that! Even if you persistent_connect with the original parameters! This is because the backend is never terminated and retains the last state, being it a ABORT STATE or another DB... :) queriing "ROLLBACK WORK;" right after the conect is my best shot at this one. Regards, Nuno Silva -- 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]
Re: [PHP] Persistent connections and transactions
Frank Joerdens wrote:
On Thu, Jan 25, 2001 at 05:10:54PM -0300, Martin A. Marques wrote:
[ . . . ]
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.
I thought one of the points being raised (can't find the mail/thread I'm
referring to now) was that somehow confusion might ensue from a mix-up,
on the Apache/PHP level, regarding the client identity, thus corrupting a
transaction in progress. It seemed to make sense but now that we've
discussed it, I can't see anymore how it might happen.
. . . [ goes away to search mail archives ] . . .
Ah, here we go. A post from Rod Taylor on pgsql-hackers on Dec 27:
-- begin quote --
The *real* problem with persistent connections is:
Script1: BEGIN;
Script1: UPDATE table set row = 'things';
Script2: Insert into table (id) values ('bad data');
Script1: COMMIT;
Since script2 managed to do a BAD insert in the middle of script1's
transaction, the transaction in script1 fails. Obvious solution? Don't
do
connection sharing when a transaction is enabled. The whole persistent
connection thing is only valid for mysql as it's the only thing that
doesn't
really support transactions (and even thats partially changed).
They need to look for stuff going through (keywords like BEGIN) and
'lock'
that connection to the single entity that opened it.
It's much easier to write your own. I wrote a few functions like:
get_connection('DB PARMS');
begin_transaction();
commit_transaction();
close_connection();
-- end quote --
[ . . . ]
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.
Those where my thoughts too (or, rather, Adams thoughts ;)), and this is
what I am trying at the moment.
Regards, Frank
hi,
i ran across this transaction problem vs. persistent conn in pgsql some time ago.
I found two workaround methods:
- don't use persistent conn's :-) or;
- start every conn with the usual pg_pconnect and then query a rollback to the server:
$query="ROLLBACK work;"
(this will kill any supposed transaction in ABORT STATE that some child had left).
postgres don't support nested transactions (yet), but when it does maybe you should
add multiple "ROLLBACK WORK;" queries :-)
Regards,
Nuno
--
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]
Re: [PHP] Persistent connections and transactions
On Fri, Jan 26, 2001 at 11:01:14AM +, Nuno Silva wrote: [ . . . ] i ran across this transaction problem vs. persistent conn in pgsql some time ago. I found two workaround methods: - don't use persistent conn's :-) or; - start every conn with the usual pg_pconnect and then query a rollback to the server: $query="ROLLBACK work;" (this will kill any supposed transaction in ABORT STATE that some child had left). postgres don't support nested transactions (yet), but when it does maybe you should add multiple "ROLLBACK WORK;" queries :-) Ah. Very cool. What I _still_ don't quite understand, though, is _how_ exactly this situation could come about. And what the worst case would be. What if you don't kill the transaction in ABORT STATE? Ta, Frank -- 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]
Re: [PHP] Persistent connections and transactions
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.9090M: 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]
[PHP] Persistent connections and transactions
On the PostgreSQL lists there has been some discussion recently as to the mechanism behind, benefits and drawbacks, of persistent connections. In particular a scenario similar to the following was brought up: Browser A connects to Apache child N, and calls a web page that calls a script which issues SQL commands that involve opening and committing a transaction: - begin work; - do some selects, inserts, deletes, updates . . . Now, the question is: Is it conceivable that in the meantime, whilst Browser A is waiting for the output from the script, that Browser B talks to same Apache child, uses the same persistent connection, and messes up the transaction that Browser A initiated in some unpredictable way? - do more selects, inserts, deletes, updates . . . - commit work; My guess would be that the Apache child wouldn't allow Browser B to talk to it whilst Browser A is waiting for output from the script and that that means that everything is fine and hunky-dory . . . I'm not sure though, and there is nagging trace of murkiness. Cheers, Frank -- 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]
Re: [PHP] Persistent connections and transactions
On Thu, Jan 25, 2001 at 11:18:49AM -0300, Martin A. Marques wrote: [ . . . ] No, and thats why in the postgres list we talked about persistent connections not having much benefits. That is because the connection is persistent to the httpd child that called it and not to all. Well, yes, but as long as the child lives, it'll be connected which means that every subsequent request to this child involving a database connection won't have to suffer the connection startup cost. If you have a rather inexpensive query, and a lot of web apps use simple, straightforward selects that are very inexpensive, then the connection startup overhead contributes more to the performance hit than the actual query. [ . . . ] Now be carefull. http connection open and close, they do not stay open, so if you try to execute different SQL statments with different httpd connections, your gonna have trouble (the sql server won't let you, because there is another transaction been executed). Hmm. Say the Apache child is idle (under which cirumstances exactly does it consider itself 'idle'?), receives a request for a page which executes a query (because it contains php code that does). This takes a while. In the meantime, while the SQL server is chugging away running the query, will the Apache child not accept further http requests? How does the Apache child know that it is waiting for the query to complete? This is what I don't know about the mechanism. Regards, Frank -- 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]
Re: [PHP] Persistent connections and transactions
El Jue 25 Ene 2001 14:34, Frank Joerdens escribi: On Thu, Jan 25, 2001 at 11:18:49AM -0300, Martin A. Marques wrote: [ . . . ] No, and thats why in the postgres list we talked about persistent connections not having much benefits. That is because the connection is persistent to the httpd child that called it and not to all. Well, yes, but as long as the child lives, it'll be connected which means that every subsequent request to this child involving a database connection won't have to suffer the connection startup cost. If you have a rather inexpensive query, and a lot of web apps use simple, straightforward selects that are very inexpensive, then the connection startup overhead contributes more to the performance hit than the actual query. Of course. But the persistent connection are not working as the manuals say they should work. [ . . . ] Now be carefull. http connection open and close, they do not stay open, so if you try to execute different SQL statments with different httpd connections, your gonna have trouble (the sql server won't let you, because there is another transaction been executed). Hmm. Say the Apache child is idle (under which cirumstances exactly does it consider itself 'idle'?), receives a request for a page which executes a query (because it contains php code that does). This takes a while. In the meantime, while the SQL server is chugging away running the query, will the Apache child not accept further http requests? How does the Apache child know that it is waiting for the query to complete? This is what I don't know about the mechanism. 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. Saludos... :-) -- System Administration: It's a dirty job, but someone told I had to do it. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas - -- 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]
Re: [PHP] Persistent connections and transactions
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. - Martn Marqus email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://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]
Re: [PHP] Persistent connections and transactions
On Thu, Jan 25, 2001 at 05:10:54PM -0300, Martin A. Marques wrote:
[ . . . ]
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.
I thought one of the points being raised (can't find the mail/thread I'm
referring to now) was that somehow confusion might ensue from a mix-up,
on the Apache/PHP level, regarding the client identity, thus corrupting a
transaction in progress. It seemed to make sense but now that we've
discussed it, I can't see anymore how it might happen.
. . . [ goes away to search mail archives ] . . .
Ah, here we go. A post from Rod Taylor on pgsql-hackers on Dec 27:
-- begin quote --
The *real* problem with persistent connections is:
Script1: BEGIN;
Script1: UPDATE table set row = 'things';
Script2: Insert into table (id) values ('bad data');
Script1: COMMIT;
Since script2 managed to do a BAD insert in the middle of script1's
transaction, the transaction in script1 fails. Obvious solution? Don't
do
connection sharing when a transaction is enabled. The whole persistent
connection thing is only valid for mysql as it's the only thing that
doesn't
really support transactions (and even thats partially changed).
They need to look for stuff going through (keywords like BEGIN) and
'lock'
that connection to the single entity that opened it.
It's much easier to write your own. I wrote a few functions like:
get_connection('DB PARMS');
begin_transaction();
commit_transaction();
close_connection();
-- end quote --
[ . . . ]
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.
Those where my thoughts too (or, rather, Adams thoughts ;)), and this is
what I am trying at the moment.
Regards, Frank
--
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]
