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
