I had expected at most 8 php-cgi children, having configured
PHP_FCGI_CHILDREN=8in the wrapper script, but mod_fcgid was clearly starting multiple instances of the wrapper, so I was getting an absurd number of children.
I discovered FcgidMaxProcesses and further benchmarks ensued:
The first two rows, in spite of the second only providing 40% of the available PHP children, are within error of each other in actual performance. The third line produces a total of 20 children again, but now 10 of them instead of 4 are visible in mod_fcgid for handling requests.
Clearly, there are too many cooks in the kitchen: both mod_fcgid and php-cgi (which, I should mention, was built with
--disable-fpm) are trying to act as master, so PHP ends up wasting
$PHP_FCGI_CHILDREN - 1processes because mod_fcgid won't pass concurrent requests for them to handle.
What happens if you don't configure
PHP_FCGI_CHILDRENat all? php-cgi handles the request directly, as if it were a child to begin with, and pstree looks more like this:
That looks rational. How does it perform?
Concurrency was held the same at 16 throughout all tests today, so it looks like we've run into the limits of the 100 mbit network. (Serious benchmarking will happen once my gigabit gear arrives.) Still, the fact that performance keeps up with 10×2 children portends well; it means there's no penalty for unsetting
PHP_FCGI_CHILDRENand mod_fcgid isn't broken without it.