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

i'm going to specify at apache now :) Sunday, April 15, 2001, 8:52:59 PM, you wrote: > But my point is that the communication overhead is still gained by process > based systems. True they don't have the same pooling ability, as does a > threaded process management. Overhead saved using pconnect is that which is > being debated here. that is only the case for *optimal* configured system. Just for those who don't know, Apache is configured by utilising "MinClients" (number of min. worker processes), "MaxClients" (max. number of worker processes), "MinSpareServers" (min. number of unused worker processes) and "MaxSpareServers" (max. number of unused worker processes). Now let's compare multi-thread and multi-process based systems :) Threads: the max number of pconnects is valid for *all* threads of the parent process, also *every* persistent connections made by *every* thread is shared. Process: the max number of pconnects is only valid for *one* working process, the connections can't be shared amongst the working processes in the worst case you'll have (pconnects * (user/password combinations) * MaxClients) If one worker process already made a connection to the db, short time after another worker process making a pconnect using the same user/password combination, they still will use different connections. While in the thread based the next thread simply reuses the connection made by the other thread. Another big disadvantage is that if "MaxSpareServers" is reached, the manager process wil begin the shutdown the unused worker processes until "MinSpareServers" is reached. Surely the persistent connections by those unused processes are closed as well. So if you're using a process based system there *has* to be alot of more connectivity to be done when compared to a thread based system under the same load. daniel /*-- daniel beulshausen - daniel@php4win.de using php on windows? http://www.php4win.de