Re[2]: [PHP-WIN] MySql pconnect

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 - daniel@php4win.de using php on windows? http://www.php4win.de