http://www.webtechniques.com/archives/2001/01/jagielski/
Skip down to where it mentions databases...very enlightening.
I think I may just consider slipping a "p" into my db_connect() function :)
--
Plutarck
Should be working on something...
...but forgot what it was.
"Daniel Beulshausen" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Sunday, April 15, 2001, 3:38:48 PM, you wrote:
> > 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.
>
> sure it can, but that's why it only works for threaded sapi's.
>
> like in every threaded application, the threads of the parent process
share the same name/access space, and that space is
> persistent until the parent process exits.
> so persistent storage between requests can't work for the cgi, as it's
> shuting down on each webserver request, while the server module is
> only shuting down if the server goes down.
> if you're using normal connects php is registering the connection(s) of
the
> actual page for the working thread, other threads can't access it.
> on request shutdown (php is finished parsing the page) php closes
> those connections, if you forgot to.
> the pconnects work different, php manages an hash of connections which
> is shared amongst the threads, upon a new connection request php
> simply looks if the hash holds a connection that isn't locked/used by
> another thread. if there's one connection available php is locking and
reusing the open
> connection, if there's no connection available php creates another one
> and adds that to the hash.
> when the page is finished, php unlocks/makes the connection reusable
> to the other threads.
> only upon the server shutdown (or after the connections are timing
> out) those connections are closed.
>
> > 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".
>
> the mysql connects are fast already, so the performance gain shouldn't
> be too high, but for other db's (i.e. oracle or mssql, which take care of
> alot more things during the logon) the pconnect can really speed
> things up.
>
> > 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.
>
> why is this a downside? the connections are reused.
>
> > Many different persistant connections = bad
> > Only a few constantly used ones = good
>
> there will always be more normal connections (just as many as php
> processes), which are open/close in
> short intervals (and that is producing the overhead!), as compared to
> pconnects, where there would be as much connections as php processes
> in the worst case.
>
> daniel
>
> /*--
> daniel beulshausen - [EMAIL PROTECTED]
> using php on windows? http://www.php4win.de
>
>
>
> --
> 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]
