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:ceo@xxxxxxxxx] Sent: Thursday, October 12, 2006 1:37 PM To: Bauer, Jay W Cc: Roman Neuhauser; 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 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
