RE: [PHP] Re: Understanding persistent connections with oci8
-Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 5:50 PM To: Bauer, Jay W Cc: php-general@lists.php.net; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael; Bauer, Jay W Subject: RE: [PHP] Re: Understanding persistent connections with oci8 On Thu, October 12, 2006 12:52 pm, Bauer, Jay W wrote: Under the current situation these won't go away, unless there is a lot of other traffic for the webserver and the httpd servers need to free up these idle connections to handle other requests. But if there's no traffic, then does it really matter if the idle connections are sitting around?... jwb There can be lots of other network traffic on the system and a socket in use is a socket in use. It is a jwb very common complaint from customers about sockets being open that aren't being used and how to get rid of jwb them without killing the application. That is the issue that I can see coming up and is the reason our jwb customer in Japan started asking about this timeout option in the first place. Given something along these lines in a more real world setup, what makes sense? Given this scenario, if there is going to be a timeout, it almost needs to be an active one. And something simple along the lines of garbage collector that checks once an hour for connections that have gone and terminates them. But that requires more code in PHP. Not just more code LOTS more code, and very complicated. It's got to be inter-process aware, it's got to wake up some kind of assassin daemon, it's got to not consume hardly any resources, ... The only need demonstrated for an active GC is the incorrect perception that PHP should work that way. It just doesn't. Demonstrate a real need for the resources to be freed up when they aren't. Or provide a cheap and easy patch to free them up. Or, write a cron job to get a 0-byte file and uses ab to tickle enough of the Apache children that the connections go away, and tell your customer that you fixed it. :-) Actually, here's an even more attractive option: Set up httpd.conf such that the Apache children are dying off soon enough and fast enough after being idle, that THEY release the connection. Not to mention that they'll free up whatever resources the dormant Apache children are using. jwb I coming to conclusion that this timeout is not going to really act as a true idle timeout, and the cost of jwb doing so is too high. The need to terminate the unwanted persistent connections is going to need to be jwb handled a different way. And there are lots of ways to do it, and at this point is an open question. -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
-Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 5:56 PM To: Bauer, Jay W Cc: Roman Neuhauser; php-general@lists.php.net; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael; Bauer, Jay W Subject: RE: [PHP] Re: Understanding persistent connections with oci8 On Thu, October 12, 2006 1:21 pm, Bauer, Jay W wrote: I agree and right now all there is in the way of tools for an administrator to use within the PHP configuration is the number of persistent connections per server and the timeout interval. These are a bit crude as tools, but as the persistent_timeout now works it is useless as a tool to tear down unneeded, expensive connections that are no longer being used. No. It works fine. It just tears them down LATER than you expect, and only under conditions that make sense to tear them down... Run your tests again, but wait for the timeout duration, and then ab a non-OCI file with N requests at once. N OCI connections should disappear. You've done this for one connection, and it went away, as expected. Scale your one-connection test up to N. jwb I'd be very surprised if what you are suggesting wouldn't work. That is exactly what I'd expect, too. The jwb problem is I don't think any one would want to configure and run their Apache web server that way. Most try jwb to anticipate how many servers they need, persistent and non-persistent in our case, and run that way with a jwb little head room in total count. If all we have to be concerned with are the sockets being used by Apache, jwb we see that if we start hitting the max number of servers, and we need more non-persistent connections, the jwb httpd servers will terminate the idle ones for the new requests. So Apache can pretty much maintain a jwb balance between the two. The problem again gets back to the over all use of the system, if there are lots of jwb the persistent_connections still there, not being used, and the apache non-persistent load isn't high enough jwb to shutdown the persistent_connections, how can that be done. Again I'm coming to the point that I think jwb having the timeout do it is too expensive. -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
On Wed, October 11, 2006 3:42 pm, Bauer, Jay W wrote: From our testing of multiple connections we could easily create 50 of these persistent connections and would have to hit the apache web server pretty hard with a 1000 requests at 50 at a time to get these to terminate after the timeout. That seems excessive... Are you saying you have 1000 Apache children and 50 different OCI logins, for 50,000 persistent connections? Because it seems to me that you're going to swamp your RAM way too soon for that to be a workable setup... Even so, you would only need 1000 hits to kill off any stale connections, one per Apache child process. And there's not much point in hitting more often than the time limit of a single connection, really, as it's just overkill, in any reasonable scenario. Of course, it's only the luck of the draw which child you get -- In an ideal world, you could target each Apache child by PID and ping it to purge stale connections, I suppose... Still, if you're talking 1000 children and 50 OCI logins, you've pulled out the Wrong Weapon. Persistent Connections are not a magic silver bullet -- They are effective for an oft-used username/password/db setup, with one connection per Apache child process. If you're trying to make the work for 1000 children and 50 OCI logins, don't do that :-) Go back to non-persitent connections, because they're the Right Weapon for your usage. But that does work, so that is one data point and limit when setting this idle timeout. What I think should also happen if the timeout is set, and the persistent connection goes idle long enough it should be marked as a candidate for shutting down. But that is how it works, in effect -- The problem is, who shuts it down when? PHP has to be awake and active to do the shutdown. PHP itself if it goes to use this stale connection, should kill it and use another connection, hopefully a non-stale persistent connection. But that's silly. If it needs a connection, and it's already got a connection, even a just-went-stale connection, and the connection parameters match up, why in the world would it tear that connection down only to use another not-quite-stale-yet connection, or, worse, build up a whole new connection. That's just daft, really, if you think about it. And actually, Kiran in our lab proposed that as a very easy fix to implement, and we've tested it and it works fine. In other words we make 50 persistent connections, with the timeout at 10 seconds, wait a minute and then make another round of the same php requests. With the fix we proposed all new php connections are made. So we know this works. I think if this was implemented and the documentation was clear that what the persistent timeout provided was for these connections to be shutdown when every a new connection tried to use them, PHP or not, that would go along way to satisfying most customers. Especially if it clearly and cleanly documented that was how it worked. I'm afraid not -- If I understand your proposal, you would throw away perfectly good, if slightly stale, connections, only to re-build a new one right after that. That dog won't hunt. There seems to me to be several ways to implement this persistent_timeout that would make it act like how most idle timeouts work, and I agree if we can come up with some simple, low overhead ways that are well documented that would do the trick. Feel free to submit a patch -- Even the one you have now. Worst that can happen is the OCI maintainer can tell you exactly why it's not usable. Please understand: I am *NOT* an expert on this stuff, and could be 100% wrong in my armchair analysis. I don't think I've ever even *used* OCI. -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
Hi Roman, As our customers see this, they think if they set a timeout of 10 seconds, that when these connections aren't used for hours they should go away. And I can understand that. As I understand the current workings, I can see an argument for keeping things as they are, but if that is the case the current behavior needs to documented. In a sense the documentation is the bug. And yes whatever is done will be change in behavior, and it may be a design change or it might be a fix, it really isn't all that important. What I like to see is the documentation and behavior match. They don't now. Regarding there being a way to query the age of the connection, what was found is that when the timeout occurred there is a easy check that can be made to see if it has happened. Currently that is never checked once the connection is opened. The fix our lab tried was to check if the timeout happened whenever the an attempt was made to use the open connection again. If the timeout had occurred, then the connection was closed. It is a passive check, and I think reasonable. Again if someone is using this oci8.persistent_timeout they are using it because they want a way of controlling how long these connections stay around. And given this is a timeout for idle connections, it is our customer's expectation that these connections will terminate. What I see as needed is clear documentation regarding how this timeout works and what it does and under what circumstances a persistent connection will terminate when the timeout is set to a time other than -1, or infinite. I don't see this as a major coding issue, simply one of documentation and possibly implementing a small change which would actually implement an action once the timeout occurred. Obviously this 10 sec timeout being used is for testing to see the behavior, I would expect that normally the time, if not -1 and infinite would be more along the line of hours in the real world. Thanks and regards, Jay -Original Message- From: Roman Neuhauser [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 9:25 PM To: Bauer, Jay W Cc: [EMAIL PROTECTED]; php-general@lists.php.net; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael; Bauer, Jay W Subject: Re: [PHP] Re: Understanding persistent connections with oci8 # [EMAIL PROTECTED] / 2006-10-11 16:42:06 -0400: And actually, Kiran in our lab proposed that as a very easy fix to implement, and we've tested it and it works fine. In other words we make 50 persistent connections, with the timeout at 10 seconds, wait a minute and then make another round of the same php requests. With the fix we proposed all new php connections are made. So we know this works. I think if this was implemented and the documentation was clear that what the persistent timeout provided was for these connections to be shutdown when every a new connection tried to use them, PHP or not, that would go along way to satisfying most customers. Especially if it clearly and cleanly documented that was how it worked. That's not so much a fix as a different behavior. FWIW the current one is perfectly sensible in other circumstances. Is there a way to query the age of the connection? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Understanding persistent connections with oci8
On Thu, October 12, 2006 12:10 pm, Bauer, Jay W wrote: Again if someone is using this oci8.persistent_timeout they are using it because they want a way of controlling how long these connections stay around. Actually, that's an over-simplification of the purpose of persistent and timeout The purpose of persistent is to avoid spending CPU cycles tearing down and building up complex data structures with large buffers, while maintaining the security/integrity of any given user/pass should have 0 chance of accessing persisted (to coin a word) data that is not their data. The purpose of timeout is to tear down unused expensive connections if they are not actively being used, or about to be used in 1 microsecond. Once you understand this, the PHP behaviour makes perfect sense. It is a very very very common mis-perception, and your customers are not the first, and won't be the last, to complain that it's broken. What I see as needed is clear documentation regarding how this timeout works and what it does and under what circumstances a persistent connection will terminate when the timeout is set to a time other than -1, or infinite. Put it in the User Contributed Notes. :-) I don't see this as a major coding issue, simply one of documentation and possibly implementing a small change which would actually implement an action once the timeout occurred. Obviously this 10 sec timeout being used is for testing to see the behavior, I would expect that normally the time, if not -1 and infinite would be more along the line of hours in the real world. I have no idea what real world times are, but would never presume that they'd be hours rather than 10 seconds... Each active persistent connection ties up valuable resources. The cost/benefit ratio has to be examined carefully and tweaked under real-world load in dev box tests to be sure you're doing something sensible. -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
Hi Richard, That seems excessive... Are you saying you have 1000 Apache children and 50 different OCI logins, for 50,000 persistent connections? That would indeed be excessive. No there are only a max during the running of ab maybe a 100 apache children and some 50 persistent connections. We use the ab bench mark tool to generate a lot of traffic to see how things work in an extreme condition to see what we could break. When the ab finishes we have 50 persistent connections just setting there doing nothing. This is not a normal environment. But I can use lower numbers and see the same behavior, it was just easier to see the limits by doing it this way. And as I've said multiple time, even under these extreme conditions the persistent connections themselves work just fine. And we can do one run where we create 50 persistent connections, do another run where we have another 1 requests coming in at 50 requests at a time and there are no new persistent connections and none lost, they handle the load just fine. In the real world I'd expect this timeout to be set in the terms of hours not seconds. And customer's would want these connections to be terminated after this time if they had been idle say for 4 hours. In the real world I could see an environment that during say a 4 hour period of the day there are lots of users in the oracle data base, and say 20 or 25 persistent connections get set up and used over and over again during that time. And customer sets the oci8.persistent_timeout to 4 hours, so after the 4 hours of peak activity all of these connections will stay available for at least 4 more hours, and maybe 5 of them get some use. After that time I can see them to expect that some of these persistent connections will now start terminating because they aren't being used any more. Under the current situation these won't go away, unless there is a lot of other traffic for the webserver and the httpd servers need to free up these idle connections to handle other requests. Given something along these lines in a more real world setup, what makes sense? Given this scenario, if there is going to be a timeout, it almost needs to be an active one. And something simple along the lines of garbage collector that checks once an hour for connections that have gone and terminates them. But that requires more code in PHP. As I've alluded to before, in some sense why is there even an idle timeout with persistent connections. It currently doesn't do anything, and to get it to really act like an idle timeout would require some changes in the code that aren't really justified. But if timeout is available how it works needs to be clearly documented so it is clear to anyone using it how it should behave. Thanks again for your thoughtful and thought provoking discussion. Regards, Jay -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 12:41 PM To: Bauer, Jay W Cc: php-general@lists.php.net; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael; Bauer, Jay W Subject: RE: [PHP] Re: Understanding persistent connections with oci8 On Wed, October 11, 2006 3:42 pm, Bauer, Jay W wrote: From our testing of multiple connections we could easily create 50 of these persistent connections and would have to hit the apache web server pretty hard with a 1000 requests at 50 at a time to get these to terminate after the timeout. That seems excessive... Are you saying you have 1000 Apache children and 50 different OCI logins, for 50,000 persistent connections? Because it seems to me that you're going to swamp your RAM way too soon for that to be a workable setup... Even so, you would only need 1000 hits to kill off any stale connections, one per Apache child process. And there's not much point in hitting more often than the time limit of a single connection, really, as it's just overkill, in any reasonable scenario. Of course, it's only the luck of the draw which child you get -- In an ideal world, you could target each Apache child by PID and ping it to purge stale connections, I suppose... Still, if you're talking 1000 children and 50 OCI logins, you've pulled out the Wrong Weapon. Persistent Connections are not a magic silver bullet -- They are effective for an oft-used username/password/db setup, with one connection per Apache child process. If you're trying to make the work for 1000 children and 50 OCI logins, don't do that :-) Go back to non-persitent connections, because they're the Right Weapon for your usage. But that does work, so that is one data point and limit when setting this idle timeout. What I think should also happen if the timeout is set, and the persistent connection goes idle long enough it should be marked as a candidate for shutting down. But that is how it works, in effect -- The problem is, who shuts it down when? PHP has to be awake
RE: [PHP] Re: Understanding persistent connections with oci8
Hi again Richard, Excellent points about the purpose of persistent connections and timeout. But let's get to your concluding statement: Each active persistent connection ties up valuable resources. The cost/benefit ratio has to be examined carefully and tweaked under real-world load in dev box tests to be sure you're doing something sensible. I agree and right now all there is in the way of tools for an administrator to use within the PHP configuration is the number of persistent connections per server and the timeout interval. These are a bit crude as tools, but as the persistent_timeout now works it is useless as a tool to tear down unneeded, expensive connections that are no longer being used. I would think in a customer site, that the customer database and network administrators would be the ones making decisions or providing the input on when to let persistent connections go unencumbered and when to start cutting them down during what ever cycles of business they use. Now obviously the oci8.persistent_timeout as it now implemented will be of no help here at all. So the question here may be more of is the oci8.persistent_timeout a possible tool with changes to use for this, or should there be something, may outside of php used. And if the latter, is there any reason to even have the oci8.persistent_timeout. I need to spend some cycle talking to the php maintainers to see if we can come to some understanding. Thanks and regards, Jay -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 1:37 PM To: Bauer, Jay W Cc: Roman Neuhauser; php-general@lists.php.net; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael; Bauer, Jay W Subject: RE: [PHP] Re: Understanding persistent connections with oci8 On Thu, October 12, 2006 12:10 pm, Bauer, Jay W wrote: Again if someone is using this oci8.persistent_timeout they are using it because they want a way of controlling how long these connections stay around. Actually, that's an over-simplification of the purpose of persistent and timeout The purpose of persistent is to avoid spending CPU cycles tearing down and building up complex data structures with large buffers, while maintaining the security/integrity of any given user/pass should have 0 chance of accessing persisted (to coin a word) data that is not their data. The purpose of timeout is to tear down unused expensive connections if they are not actively being used, or about to be used in 1 microsecond. Once you understand this, the PHP behaviour makes perfect sense. It is a very very very common mis-perception, and your customers are not the first, and won't be the last, to complain that it's broken. What I see as needed is clear documentation regarding how this timeout works and what it does and under what circumstances a persistent connection will terminate when the timeout is set to a time other than -1, or infinite. Put it in the User Contributed Notes. :-) I don't see this as a major coding issue, simply one of documentation and possibly implementing a small change which would actually implement an action once the timeout occurred. Obviously this 10 sec timeout being used is for testing to see the behavior, I would expect that normally the time, if not -1 and infinite would be more along the line of hours in the real world. I have no idea what real world times are, but would never presume that they'd be hours rather than 10 seconds... Each active persistent connection ties up valuable resources. The cost/benefit ratio has to be examined carefully and tweaked under real-world load in dev box tests to be sure you're doing something sensible. -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
On Thu, October 12, 2006 12:52 pm, Bauer, Jay W wrote: Under the current situation these won't go away, unless there is a lot of other traffic for the webserver and the httpd servers need to free up these idle connections to handle other requests. But if there's no traffic, then does it really matter if the idle connections are sitting around?... Given something along these lines in a more real world setup, what makes sense? Given this scenario, if there is going to be a timeout, it almost needs to be an active one. And something simple along the lines of garbage collector that checks once an hour for connections that have gone and terminates them. But that requires more code in PHP. Not just more code LOTS more code, and very complicated. It's got to be inter-process aware, it's got to wake up some kind of assassin daemon, it's got to not consume hardly any resources, ... The only need demonstrated for an active GC is the incorrect perception that PHP should work that way. It just doesn't. Demonstrate a real need for the resources to be freed up when they aren't. Or provide a cheap and easy patch to free them up. Or, write a cron job to get a 0-byte file and uses ab to tickle enough of the Apache children that the connections go away, and tell your customer that you fixed it. :-) Actually, here's an even more attractive option: Set up httpd.conf such that the Apache children are dying off soon enough and fast enough after being idle, that THEY release the connection. Not to mention that they'll free up whatever resources the dormant Apache children are using. -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
On Thu, October 12, 2006 1:21 pm, Bauer, Jay W wrote: I agree and right now all there is in the way of tools for an administrator to use within the PHP configuration is the number of persistent connections per server and the timeout interval. These are a bit crude as tools, but as the persistent_timeout now works it is useless as a tool to tear down unneeded, expensive connections that are no longer being used. No. It works fine. It just tears them down LATER than you expect, and only under conditions that make sense to tear them down... Run your tests again, but wait for the timeout duration, and then ab a non-OCI file with N requests at once. N OCI connections should disappear. You've done this for one connection, and it went away, as expected. Scale your one-connection test up to N. -- 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
Re: [PHP] Re: Understanding persistent connections with oci8
On 12 Oct 2006, at 11:10 , Bauer, Jay W wrote: Again if someone is using this oci8.persistent_timeout they are using it because they want a way of controlling how long these connections stay around. Well, are they really? I would think they are using it to free up idle connections for use with new connections. That seems reasonable. And they are saying, Even if a connection appears to be idle right now, I only want it considered idle if there's been no activity in x seconds. I can see how it's not what you expected, but it still seems reasonable. Look at it this way, there's no point checking if an idle connection needs to be closed unless the idle connection is needed elsewhere. -- Bishops move diagonally. That's why they often turn up where the kings don't expect them to be. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] 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:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 4:49 PM To: Bauer, Jay W Subject: RE: [PHP] 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 tcp0 0 15.42.227.146.5926215.106.72.129.1521 ESTABLISHED 30 sends later: netstat -an |grep 1521 tcp0 0 15.42.227.146.5926215.106.72.129.1521 ESTABLISHED 2 minutes later: netstat -an |grep 1521 tcp0 0 15.42.227.146.5926215.106.72.129.1521 ESTABLISHED 5 minutes later: netstat -an |grep 1521 tcp0 0 15.42.227.146.5926215.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
RE: [PHP] Re: Understanding persistent connections with oci8
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/apachemore 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/apachetail 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/jwbaudate Wed Oct 11 20:17:34 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 ESTABLISHED /user/jwbaudate Wed Oct 11 20:21:26 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 ESTABLISHED /user/jwbaudate Wed Oct 11 20:21:45 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 ESTABLISHED /user/jwbaudate Wed Oct 11 20:23:20 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 ESTABLISHED /user/jwbaudate Wed Oct 11 20:25:09 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 ESTABLISHED /user/jwbaudate Wed Oct 11 20:31:21 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 TIME_WAIT /user/jwbaudate Wed Oct 11 20:32:11 IST 2006 /user/jwbaunetstat -an|grep 1521 tcp0 0 15.42.227.146.6236515.106.72.129.1521 TIME_WAIT /user/jwbaudate Wed Oct 11 20:33:35 IST 2006 /user/jwbaunetstat -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: [EMAIL PROTECTED]; 'php-general@lists.php.net' Cc: '[EMAIL PROTECTED]'; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael Subject: RE: [PHP] 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:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 4:49 PM To: Bauer, Jay W Subject: RE: [PHP] 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
RE: [PHP] Re: Understanding persistent connections with oci8
On Wed, October 11, 2006 8:46 am, Bauer, Jay W wrote: 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. Okay, so here's the thing... At what point in the process of normal web-server operations would you expect PHP to notice that the connection is stale and it should die? It's clear, to me, and to many others, that the problem here is not that it doesn't work -- Just that it works in a non-intuitive way for perfectly logical technical reasons. To clarify this, consider your one-process, one-user, one-hit test. Time 00:00 User asks for URL that accesses DB 00:01 PHP opens persistent connection 00:02 PHP returns HTML to user [It's probably not really 2 seconds, but let's just pretend.] At this juncture, Apache and PHP pretty much just go back to sleep, and don't do anything at all until something else comes along to wake them up. If the next thing to wake them up authenticates against the DB, and starts using the connections, then they are re-used, because they are already there, and there is no sense in tearing down a perfectly good stale connection if you're about to build another one. If the next thing to wake them up does NOT use the DB connection, the connection is noticed to be stale and killed off. This is how it works, as far as we can see from your testing. So there are several possible solutions here. PHP could set some kind of timer to wake itself up, check any outstanding persistent connections, and kill them off. This would need to be managed so that there is only one active timer and its wake-up time is extended as various events occur, since you wouldn't want it doing too much extra work that PHP is already doing. That would probably involve a great deal of inter-process communication and some significant overhead. The other option, cheap and easy, is to behave the way it does now: If somebody wakes PHP up, and it sees a stale connection, and it's not gonna use that stale connection, it kills it off. Now for MOST users, on MOST real-life scenarios, the cheap and easy solution is best. For those who have an unusual case, such as your dev server, a cron job to heartbeat a non-DB page every X minutes is a no-brainer, once one understands what's going on and why. You are certainly welcome to code and submit a patch to PHP to make it wake up and kill off stale connections, if you really think this is absolutely crucial... But if it has the kind of overhead I suspect it would have, it's not likely to be implemented. Or you could run a heartbeat cron job to a non-DB connection just a little bit longer than your connection time-out, and call the problem solved. NOTE: I am NOT an expert on PHP internals, and may be grossly incorrect about all this. I'm just giving my perception of your test results, based on how HTTP / Apache/ PHP generally work. PS I think this is how all the persistent connections operate... -- 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
RE: [PHP] Re: Understanding persistent connections with oci8
Hi Richard, You've asked the $64,000 question. What is a reasonable way for this timeout to work? Unfortunately we haven't gotten far with the bug.php.net folks to ask the question. I agree with you that providing an active thread or process to go out and check for idle persistent connections is too much overhead. I think what is needed is a little investigation to see what can be reasonable done if a customer wants to use the oci8.persistent_timeout to limit how long these connections hang around. From our testing of multiple connections we could easily create 50 of these persistent connections and would have to hit the apache web server pretty hard with a 1000 requests at 50 at a time to get these to terminate after the timeout.But that does work, so that is one data point and limit when setting this idle timeout. What I think should also happen if the timeout is set, and the persistent connection goes idle long enough it should be marked as a candidate for shutting down. PHP itself if it goes to use this stale connection, should kill it and use another connection, hopefully a non-stale persistent connection. And actually, Kiran in our lab proposed that as a very easy fix to implement, and we've tested it and it works fine. In other words we make 50 persistent connections, with the timeout at 10 seconds, wait a minute and then make another round of the same php requests. With the fix we proposed all new php connections are made. So we know this works. I think if this was implemented and the documentation was clear that what the persistent timeout provided was for these connections to be shutdown when every a new connection tried to use them, PHP or not, that would go along way to satisfying most customers. Especially if it clearly and cleanly documented that was how it worked. I can also see environments where the system hosting apache and these persistent connections for the database is very busy, and can get large burst of PHP requests from different users accessing the data at a given time, which creates lots of persistent connections. I can see them wanting a more active mechanism for terminating any connections after the peak has ended and thinks have quieted down for awhile. I think your idea of a cron job might work there, or the same mechanism within PHP. If there was one, I'd make it optional as it would be overhead and many customers wouldn't want it. There seems to me to be several ways to implement this persistent_timeout that would make it act like how most idle timeouts work, and I agree if we can come up with some simple, low overhead ways that are well documented that would do the trick. Thanks and regards, Jay -Original Message- From: Richard Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 3:44 PM To: Bauer, Jay W Cc: php-general@lists.php.net; Bauer, Jay W; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael Subject: RE: [PHP] Re: Understanding persistent connections with oci8 On Wed, October 11, 2006 8:46 am, Bauer, Jay W wrote: 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. Okay, so here's the thing... At what point in the process of normal web-server operations would you expect PHP to notice that the connection is stale and it should die? It's clear, to me, and to many others, that the problem here is not that it doesn't work -- Just that it works in a non-intuitive way for perfectly logical technical reasons. To clarify this, consider your one-process, one-user, one-hit test. Time 00:00 User asks for URL that accesses DB 00:01 PHP opens persistent connection 00:02 PHP returns HTML to user [It's probably not really 2 seconds, but let's just pretend.] At this juncture, Apache and PHP pretty much just go back to sleep, and don't do anything at all until something else comes along to wake them up. If the next thing to wake them up authenticates against the DB, and starts using the connections, then they are re-used, because they are already there, and there is no sense in tearing down a perfectly good stale connection if you're about to build another one. If the next thing to wake them up does NOT use the DB connection, the connection is noticed to be stale and killed off. This is how it works, as far as we can see from your testing. So there are several possible solutions here. PHP could set some kind of timer to wake itself up, check any outstanding
Re: [PHP] Re: Understanding persistent connections with oci8
# [EMAIL PROTECTED] / 2006-10-11 16:42:06 -0400: And actually, Kiran in our lab proposed that as a very easy fix to implement, and we've tested it and it works fine. In other words we make 50 persistent connections, with the timeout at 10 seconds, wait a minute and then make another round of the same php requests. With the fix we proposed all new php connections are made. So we know this works. I think if this was implemented and the documentation was clear that what the persistent timeout provided was for these connections to be shutdown when every a new connection tried to use them, PHP or not, that would go along way to satisfying most customers. Especially if it clearly and cleanly documented that was how it worked. That's not so much a fix as a different behavior. FWIW the current one is perfectly sensible in other circumstances. Is there a way to query the age of the connection? -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Understanding persistent connections with oci8
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 tcp0 0 15.42.227.146.5926215.106.72.129.1521 ESTABLISHED 30 sends later: netstat -an |grep 1521 tcp0 0 15.42.227.146.5926215.106.72.129.1521 ESTABLISHED 2 minutes later: netstat -an |grep 1521 tcp0 0 15.42.227.146.5926215.106.72.129.1521 ESTABLISHED 5 minutes later: netstat -an |grep 1521 tcp0 0 15.42.227.146.5926215.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:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 4:48 PM To: Mendonce, Kiran (STSD) Cc: php-general@lists.php.net Subject: RE: [PHP] 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
RE: [PHP] Re: Understanding persistent connections with oci8
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 -Original Message- From: Mendonce, Kiran (STSD) Sent: Wednesday, October 04, 2006 10:34 AM To: php-general@lists.php.net Subject: RE: [PHP] Re: Understanding persistent connections with oci8 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 ? -Original Message- From: Manuel Lemos [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 12:16 AM To: php-general@lists.php.net Subject: [PHP] Re: Understanding persistent connections with oci8 Hello, on 10/03/2006 07:03 PM Mendonce, Kiran (STSD) said the following: 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 doesn't terminate at all. So the question is what is the purpose of this setting ? And what does an 'idle connection' mean ? A google 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. 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 Metastorage - Data object relational mapping layer generator http://www.metastorage.net/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- 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
RE: [PHP] 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? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Understanding persistent connections with oci8
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 ? -Original Message- From: Manuel Lemos [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 12:16 AM To: php-general@lists.php.net Subject: [PHP] Re: Understanding persistent connections with oci8 Hello, on 10/03/2006 07:03 PM Mendonce, Kiran (STSD) said the following: 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 doesn't terminate at all. So the question is what is the purpose of this setting ? And what does an 'idle connection' mean ? A google 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. 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 Metastorage - Data object relational mapping layer generator http://www.metastorage.net/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- 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
