ID: 39029 Updated by: [EMAIL PROTECTED] Reported By: kiranm at hp dot com -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: HP-UX PHP Version: 5.1.6 New Comment:
>If I do not want the connection to be persist forever, >then by using this setting, I should be able to ensure >that a connection is not idle for longer than what I >specified. However, when I set persistent_timeout to 10 >seconds, I find that the connection is not terminated >even after 10 seconds have passed. In fact, it doesn’t >terminate at all. So the question is what >is the purpose of this setting ? The purpose it to reduce number of open Oracle connections by closing IDLE connections. A connection can be still there after the time out if this particular process was not reused since then. Here is how it works: 1) each Apache childs maintains it's own list of persistent connections. 2) helper functions that check if it's time to close the connection are called _at shutdown_ of this particular Apache child. When you set oci8.persistent_timeout to 10 seconds, it doesn't mean that all persistent connection will be closed in 10 seconds, but only if they were _not reused_ (the timeout is refreshed at this moment) and shutdown functions were called. >And what does an 'idle connection' mean? "Idle connection" stands for "connection not being used anymore". Since you wait for 10 seconds and then re-use the connection again, it is not considered "idle" at shutdown. This is how it works and this is how it should work. If you have any further questions - feel free to contact me directly, but please keep this report marked as bogus. Previous Comments: ------------------------------------------------------------------------ [2006-10-11 19:50:10] kiranm at hp dot com This is a follow-up and reopen of bug report #39029 Persistent connections remain even after timeout has elapsed This was closed as bogus, and the problem has been posted to the php-general@lists.php.net and this is a follow up to the suggestions from those discussions. The main email involved are included. In this bug report we have tried to remove any misunderstandings about the behavior based on the inputs received. The problem as I see it is that the description of the oci.persistent_timeout in the php manual page, http://us2.php.net/manual/en/ref.oci8.php#ini.oci8 does not match it's behavior as documented in bug report #39029 and further documented below. This problem can be addressed in more than one manner. The behavior of the how the oci8.persistent_timeout works can be changed to work as described now or closer to that description, and/or the documentation can be edited so it reflects accurately how it works and is expected to work with maybe some minor code changes, or simply say that the persistent_timeout is "useless", as has been suggested in one of the emails below, and remove it as an option. Background discussion ------------------------ >From Kiran Mendonce to the php-general@lists.php.net This is a follow up to the bug (#39029) that I reported earlier which has been repeatedly closed as bogus. The oci8.persistent_timeout setting in the php.ini file is documented as : "The maximum length of time (in seconds) that a given process is allowed to maintain an idle persistent connection. Setting this option to -1 means that idle persistent connections will be maintained forever. " If I do not want the connection to be persist forever, then by using this setting, I should be able to ensure that a connection is not idle for longer than what I specified. However, when I set persistent_timeout to 10 seconds, I find that the connection is not terminated even after 10 seconds have passed. In fact, it doesnt terminate at all. So the question is what is the purpose of this setting ? And what does an 'idle connection' mean ? A goggle query for 'idle timeout' yields enough results to point that when the timeout occurs, the idle connection is terminated. Obviously there is a bug somewhere. Either in the documentation or in the behavior. Please advise. Reply from php-general@lists.php.net: I think that there is no bug and that option is useless. If you are using Apache, it will rotate the processes that serve each request. So, unless your server is mostly idle or your scripts rarely access the database, your connections will keep being reused before reaching that timeout. If you are willing to reduce the number of persistent Oracle connections, you will most likely get better results if you move your site images to a separate Web server. Image requests do not establish Oracle connections, but they raise the need for Apache to fork more processes, which leads to more opened persistent connections. Here you may find more details about that strategy: http://www.meta-language.net/metabase-faq.html#excessive-connections Regards, Manuel Lemos From: Kiran Mendonce to: [EMAIL PROTECTED] I understand the performance boost one can get by reusing existing connections. And I did see for myself that with the default settings, oci_pconnect() does reuse all the connections. But what should happen if there are idle connections and the timeout is reached? That is my question. What is the purpose of the persistent_timeout setting? Does it give the user a means of specifying a timeout after which idle connections are removed? I did some checking on the web and noticed that another user encountered a similar problem and even reported it as a bug (#36634). The documentation is misleading here with the intent of the persistent_timeout setting not clearly explained. If the behavior is as designed, can someone please update the documentation so its more clearer to the end user ? Thanks and Regards, Kiran Reply from php-general@lists.php.net: Yes. Their claim is that your tests are invalid because your have MULTIPLE Apache processing swapping the connections around, so they are NOT idle for 10 seconds. To prove them wrong, you would need to: Set up a dev server on a private network with Apache having ONE, and ONLY ONE, child. Set the timeout to 10 seconds. Surf to a test page. Wait 10 seconds. See if the connection goes away. If anybody else on the planet (or off-planet, for that matter, assuming our astronauts have time to surf to your site) can surf to the site and keep the connection "alive" by having Apache re-use it, then it's going to stay alive. Richard Lynch [EMAIL PROTECTED] Hello Richard, First let me introduce myself, I'm Jay Bauer and have been supporting the Apache webserver for the last couple of years and have been doing networking support for over 15 years. I want to thank you for explaining why the folks replying to our lab's enquiries don't think the tests are valid. I can appreciate the need of doing fault isolation of a problem so that all possible extraneous causes are eliminated. However, I don't think their specific concerns are valid, as these systems are on internal networks, and very few people access them at all, and only Kiran or I would be accessing the oracle database and that is for our tests. And yes we will get some 50 httpd servers up and running, but once we stop our testing there is little access to the system and none to these persistent connections, and they will stay around for hours or days till one of us decides to do more testing or stop and restart the Apache server. Now having said all of that, I had no problem implementing the test setup you suggested. If that is what it takes to get everyone on the same page, I'm happy to oblige. Test environment ----------------- The HP-UX Apache web server only provides the worker MPM so in order to set up Apache as requested we use the following configuration in httpd.conf: changed the worker.c configuration to: <IfModule worker.c> StartServers 1 MaxClients 1 MinSpareThreads 1 MaxSpareThreads 1 ThreadsPerChild 1 MaxRequestsPerChild 1 </IfModule> and commented out mod_cgid: #LoadModule cgid_module modules/mod_cgid.so and in php.ini: extension=oci8.sl oci8.max_persistent=1 oci8.persistent_timeout=10 oci8.ping_interval=0 And the php version information: /opt/hpws/apache/php>bin/php -v PHP 5.0.4 (cli) (built: Sep 21 2006 15:26:12) Testing -------- After starting Apache with the above httpd.conf worker configuration there are two process running: ps -ef |grep apache www 29362 29361 0 23:39:52 ? 0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start root 29361 1 0 23:39:52 ? 0:00 /opt/hpws/apache/bin/httpd -d /opt/hpws/apache -k start Pid 29361, the master httpd server, and one worker httpd server pid 29362, which is the minimum configuration possible with the worker MPM. I then ran the apache bench mark for just one connection: bin/ab -n 1 http://maggie.india.hp.com/oracle_mufasa.php ... Document Path: /oracle_mufasa.php Document Length: 334 bytes Concurrency Level: 1 Time taken for tests: 0.370606 seconds Complete requests: 1 Results and preliminary Analysis ---------------------------------- And then checked on the connection As quick as possible: >netstat -an |grep 1521 tcp 0 0 15.42.227.146.59262 15.106.72.129.1521 ESTABLISHED 30 sends later: >netstat -an |grep 1521 tcp 0 0 15.42.227.146.59262 15.106.72.129.1521 ESTABLISHED 2 minutes later: >netstat -an |grep 1521 tcp 0 0 15.42.227.146.59262 15.106.72.129.1521 ESTABLISHED 5 minutes later: >netstat -an |grep 1521 tcp 0 0 15.42.227.146.59262 15.106.72.129.1521 ESTABLISHED It wasn't until about 40 minutes later that this connection did finally terminate. And when I checked the error_log, it was clear what terminated it: [error] [client 15.10.45.59] Symbolic link not allowed: /opt/hpws/apache/htdocs/index.html [debug] worker.c(1342): taking over scoreboard slot from 29362 (quiescing) Another request finally came in to this system , which caused an error, and since there was only one server allowed to run it did and that is what killed this persistent connection. This is what we have also observed that other apache requests will cause persistent connections to be terminated, as they don't close on their own. And as said earlier this system's webserver doesn't get many hits, it is a test environment, not a production system. And as we can see it took 40 minutes for any traffic to hit this system. I hope this test is adequate to clear up the concerns that the testing is invalid. Best regards, Jay Bauer WTEC Engineer, Internet Services HP-UX Hewlett Packard Co. >From Richard: Excellent! Submit that to bugs.php.net, and you have very good odds that it won't get marked bogus and ignored. You got caught in the net of trigger-happy bug-bogus-marking before, right? It happens, but if you check through the size/scale of the bugs db... In this case, you've clearly shown that nothing else is keeping the connection "alive" Though, for one other wrinkle -- make some request after your timeout that does not "re-connect" to the persistent connection. It's possible that PHP cannot shutdown the connection after the timeout unless it's being actively run by a non-db request, if you see what I mean. Hi Richard, Yes there have been some trigger-happy, bug-bogus-marking going on, but that happens. And yes, this stays alive without anything going on. And we have tested your "other wrinkle" and that is how we have been able to end the persistent connections by making connections to a non-oracle-db request which will terminate the persistent connections. The only other way has been to restart apache. And I can redo the test with just one server and one connection and explicitly terminate the persistent connection by making a new non-oracle-db request. Thanks and regards, Jay Further Testing ------------------ This time I first enabled the access_log on maggie, so I had that history, and used browser windows to connect to http://maggie.india.hp.com/oracle_mufasa.php to set up a persistent connection and then about 15 minutes later in another browser connect to http://maggie.india.hp.com/. Within that time there were no other attempts to connect to the web server. The access_log gives the times quite clearly: /opt/hpws/apache>more logs/access_log 16.113.41.14 - - [11/Oct/2006:20:16:03 +0530] "GET /oracle_mufasa.php HTTP/1.1" 200 334 16.113.41.14 - - [11/Oct/2006:20:31:52 +0530] "GET / HTTP/1.1" 200 1456 16.113.41.14 - - [11/Oct/2006:20:31:53 +0530] "GET /apache_pb.gif HTTP/1.1" 200 2326 And the error_log entry is the same as seen in the test yesterday when the persistent connection was terminated by a random request. It is good to confirm that under this restricted configuration those are the errors we are getting: /opt/hpws/apache>tail logs/error_log ... [Wed Oct 11 20:31:52 2006] [error] [client 16.113.41.14] Symbolic link not llowed: /opt/hpws/apache/htdocs/index.html [Wed Oct 11 20:31:53 2006] [debug] worker.c(1342): taking over scoreboard slot from 11077 (quiescing) [Wed Oct 11 20:31:53 2006] [debug] util_ldap.c(1697): Initialisation of global mutex /opt/hpws/apache/ in child process 11267 successful. And using netstat and date we see the persistent connection stay ESTABLISHED till the non-oracle-db request comes in: /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 ESTABLISHED /user/jwbau>date Wed Oct 11 20:17:34 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 ESTABLISHED /user/jwbau>date Wed Oct 11 20:21:26 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 ESTABLISHED /user/jwbau>date Wed Oct 11 20:21:45 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 ESTABLISHED /user/jwbau>date Wed Oct 11 20:23:20 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 ESTABLISHED /user/jwbau>date Wed Oct 11 20:25:09 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 ESTABLISHED /user/jwbau>date Wed Oct 11 20:31:21 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 TIME_WAIT /user/jwbau>date Wed Oct 11 20:32:11 IST 2006 /user/jwbau>netstat -an|grep 1521 tcp 0 0 15.42.227.146.62365 15.106.72.129.1521 TIME_WAIT /user/jwbau>date Wed Oct 11 20:33:35 IST 2006 /user/jwbau>netstat -an|grep 1521 /user/jwbau>date Wed Oct 11 20:34:26 IST 2006 Expectations --------------- At this point I hope there aren't any concerns about something else clouding up the issue that with the oci8.persistent_timeout set at 10 seconds these connections will not terminate until Apache requires them for another non-oracle-db request. If there are other concerns, please make that concern clear, and we'll try to address it to your satisfaction. And again what we are looking for here is that the documentation about the oci8.persistent_timeout and it's behavior match, which they do not do at this time. Thanks and regards, Jay Bauer Internet Services, World-Wide Expert Center, HP ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/39029 -- Edit this bug report at http://bugs.php.net/?id=39029&edit=1
