[gkulewski]

Originally Posted by mistwang

That's the part I cannot agree with the point I mentioned earlier, suPHP should be 200% or better scalable than suHTTPD, it debatable with different workload, I will skip that, just for typical shared hosting situation, many web sites are just static.

I am not saying it should be mandatory. It should be optional.

I can only find one case when there is big overhead. When you are doing only very small amount of static HTML requests on user that has no httpd process spawned for him. And then wait till his process gets killed. And then again. And no PHP requests at the same time. In that case we get fork overhead. Not very small but can be decreased by keeping several spare processes forked that only must do setuid.

But in all real hosting loads I ever saw the case was completely different. First there was much more than one request at once (... every hundred seconds). Second - every few requests there is some PHP requests. In both cases (and especially in both at once) the accumulated performance lost is very small.

From my load:
# grep -E '(GET|POST) [^ ]+\.php' /var/log/syscplogs/*access.log* | wc -l
4193833
# cat /var/log/syscplogs/*access.log* | wc -l
45254231

And that pretty much means exactly that every 1/10 request is PHP one.