Hi Rasmus Lerdorf, you wrote. >> time spent in mutex-protected code is 99% of the total request processing >> time, then the server will scale poorly. The key success factor is to not >> use libraries that require locking for lengthy operations. RL> If, for example, we have to mutex an entire database library and every
So it is expected to break up, for example, PHP in libraries that do support threading explicitely and such that don't or aren't known to do it instead of having a mutex around all of PHP? I'm aware of the fact that request for static content will still get served and that's very nice since many sites consist of few dynamic pages and loads of images ;-) so in the end, the scalability might not suffer too much in our case as we only host low traffic sites on shared servers anyway and on the dedicated ones, prefork has proven to offer quite acceptable performance. In view of this "It's impossible to tell which libs are thread safe" wouldn't it perhaps make sense to have a perchild version that uses processed instead of threads? I sure know that this would result in a insane amount of sleeping processes in a massive Virtualhosting setup but in my tests a very low end 500Mhz FreeBSD 4.6 box with 256MB RAM had no problem whatsoever with 2000 sleeping Apache processes belonging to 250 DISTINCT instances of 1.3.26, all based upon different config files and running on different ports . Swap wasn't used and in idle state, the 2000 processes consumed less than 1.5% CPU... Regards, Gabriel
