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 10000 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:ceo@xxxxxxxxx] Sent: Thursday, October 12, 2006 12:41 PM To: Bauer, Jay W Cc: php-general@xxxxxxxxxxxxx; Mendonce, Kiran (STSD); Nikiel, Carsten; Rai, Moni (GSE WTEC Cupertino); Rieslund, Mikael; Bauer, Jay W Subject: RE: 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
