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"" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
>
>
> >
> > 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
> [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
