Hello everyone, I followed up on Richards suggested "new-wrinkle" and automated the time recording a bit better than before. Here is what I did and the results: 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 allowed: /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 date and netstat we see the persistent connection stay ESTABLISHED till the second non-oracle-db request comes in: /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 I'll put this and the data from yesterday together and submit it to bugs.php.net. Best regards, Jay -----Original Message----- From: Bauer, Jay W Sent: Wednesday, October 11, 2006 9:46 AM To: ceo@xxxxxxxxx; 'php-general@xxxxxxxxxxxxx' Cc: 'jay_bauer@xxxxxx'; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael Subject: RE: Re: Understanding persistent connections with oci8 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 -----Original Message----- From: Richard Lynch [mailto:ceo@xxxxxxxxx] Sent: Tuesday, October 10, 2006 4:49 PM To: Bauer, Jay W Subject: RE: Re: Understanding persistent connections with oci8 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. On Tue, October 10, 2006 2:01 pm, Bauer, Jay W wrote: > 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 or none to these connections, and they will stay around for > hours or days till one of us decides to do more testing and stops and > restarts 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. > > 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 > > After starting Apache we have 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 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 > > 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 errored, 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 this persistent connections to > be > terminated, 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. > > > > -----Original Message----- > From: Richard Lynch [mailto:ceo@xxxxxxxxx] > Sent: Thursday, October 05, 2006 4:48 PM > To: Mendonce, Kiran (STSD) > Cc: php-general@xxxxxxxxxxxxx > Subject: RE: Re: Understanding persistent connections with oci8 > > On Wed, October 4, 2006 12:34 pm, Mendonce, Kiran (STSD) wrote: >> 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 ? > > 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. > > -- > Some people have a "gift" link here. > Know what I want? > I want you to buy a CD from some starving artist. > http://cdbaby.com/browse/from/lynch > Yeah, I get a buck. So? > > -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
