I believe the number of processes are dictated by your site’s max concurrent users you wish to handle which then dictates your hardware resources. If you are constrained then this is another matter, but unfortunately that was not the objective of this article.

About optimal performance, I would not recommend any exact numbers, but rather server metrics collection and graphing (Collectd is great at this) and based on those graphs you can make some additional decisions. But first you have to decide whether you are optimizing page load times (user experience) or server-side stuff (better overall performance of the server, but not necessarily better for users per se).

b.

PS: Did you use PHP-FPM which is included with PHP distribution as of lately?

ITK MPM is much better in that case but not always what you want.

A third solution is something like mod_rsbac. It works with prefork MPM and mod_php, yet provide full virtualhost isolation (in fact, much better isolation any of the previous solution offers by a very long margin)

mod_rsbac is nearly the same performance as native prefork+mod_php, too

Thanks for the hint, you’re probably right. Will retest it with larger PHP-FPM process pool.

- from php-fpm.conf 16 – this limits the process pool to 16 processes for PHP-FPM while Apache can fork more children aka it can support better concurrency when the load is not CPU bound. This is the case for the HelloWorld.php test. The adaptive process spawning was implemented in PHP-FPM after the inclusion into the upstream PHP distribution, although the configuration file may state otherwise. This may be an unfair disadvantage for the PHP-FPM case. Most people say that Apache2+mod_php5 performs better for “real world applications”, but most of the time they forget to mention what’s the exact level of concurrency stated by worker MPM vs the PHP-FPM process pool since a low number of processes into the PHP-FPM pool means that requests start to queue while the CPU basically is free for other stuff. You benchmark suffers from this kind of starvation.

- you may use an UNIX domain socket for the FastCGI protocol request / response transactions which avoids the TCP overhead that your tests has, even for the loopback interface that still needs to encapsulate / decapsulate the traffic, or fragment the information which is not uncommon for real world applications as the loopback MTU is just 16436.

About your longer answers, there are some things to consider:

- .htaccess comes with some added computational cost, therefore a properly configured Apache won’t have this “advantage”. Apache is good for virtualhosting when the end client has access to the server configuration, but for an organization, that job should suit better a professional sysadmin.

- from the virtualhosting point of view, mod_php5 comes with a security issue ‘by design’ when combined with worker MPM since by default any virtualhost can access the files hosted by another virtual host. ITK MPM would avoid that. PHP’s safe_mode would avoid most of the issues as well, but that’s a nasty hack that the PHP team is going to remove anyway into the next version. The other solution is FastCGI. Proper configuration with suEXEC, open_basedir and mod_fcgid has loads of fun under Apache. PHP-FPM has a much cleaner implementation since it binds a specific process pool to its own security context by design, not by hacking configuration files and creating FastCGI wrappers.

What can I say … we ditched Apache from out production servers for quite a while. So far, nobody misses it.