Re: MySql pconnect

Hm...ok, let's see here. Persistant connection vs. non. Pros and cons...*ponder* I haven't heard a whole lot about the debate, but here is what I'm thinking. When you call pconnect when a persistant connection is already available, it is approximately the same speed as when you call connect for the second time in a script. It still is a delay. It's not "instant", because PHP has to check and see if a persistant connection is open. It can't "remember" on it's own. The speed difference with pconnect and connect is in the initial connection creation by MySQL. When a connection is requested, MySQL must create a new connection ID and respond. If a persistant connection is already available it needs only respond with the current ID. The creation of a connection can't be all that taxing, so it really doesn't matter on a per script basis, but the point is "which is better". I imagine the best use for pconnect is when the same host, username, and password connection must be called many times very often. If you are something like, say, hotornot.com, where every single page has a call to a database, I imagine pconnect would be the better way to go. The connection never needs to be closed, because you are using them constantly. The downside of pconnect is you _can't_ close the connection once it's started. If you use it only once an hour, that's 59 minutes that MySQL has to keep open an unitilized connection. With connect it would of been closed immediatly. But in a situation where you must utilize connections to a database consistantly all day, with the same hostname, username, and password, I suppose a persistant connection would be better. However, I still say that "when in doubt, use connect". There are no downsides to connect, and you can always easily switch over to using pconnect. But once you've used pconnect, the connections stay...and stay...and stay... Anyone know of an article or benchmarking study that dealt with pconnect and connect? I'd love to see the hard numbers on them. Moral of the story: It's fine to use connect until you start to notice any sort of real resource drain. Then you can try switching to pconnect and see if it hurts anything. At Datablocks.net I heard the use of pconnect was really giving the database server troubles, because it had to keep open a few thousand connections which it would much prefer just close. Eventually it maxed out the available connections until it couldn't issue more, so connections started queing, and the whole system effectively locked up. Many different persistant connections = bad Only a few constantly used ones = good -- Plutarck Should be working on something... ...but forgot what it was. ""James Moore"" <jmoore@php.net> wrote in message news:PJEKIAAHHNOGHIGKKJFDEEKFDEAA.jmoore@php.net... > > > > > > > For connect vs. pconnect, the instances where you should use pconnect are > > really rare. > > > > When in doubt, use connect. If you know of a specifically good > > reason to use > > it, then feel free. > > > > But I personally have never had a situation where pconnect worked better > > than connect. > > pconnect is better to use IMHO on any site with a decent amount of hits as > youll get better performance due to the lack of the overhead of making a new > connection every time a page is called. I would totally disagree with you > here plutarck pconnect is there to make things quicker which it does by > keeping the connection open between page requests. > > > And as for extended server status, I haven't a clue about it :) > > Never looked into it really.. probably not worth it.. try asking on the > php-db list. > > -James > -- > James Moore > jmoore@php.net > http://www.perl.com/search/index.php - we must be doing > somthing right > > > > -- > PHP Windows Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-windows-unsubscribe@lists.php.net > For additional commands, e-mail: php-windows-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >