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 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
