Olaf Greve wrote:
Will that not have some other downsides? I remember that previously when running PHP on the CGI, that e.g. a lot of debugging power got lost, as each and every error would simply either return a blank page, or simply an "internal servor error 500" or so.... Is that also the case with FastCGI?
Yes, in case of critical / setup errors (i.e. ones that happen "between" apache and php) you'll get that kind of message. Normal PHP and Apache error messages and warnings are not affected.
>BUT, if something else changed when you switched to the new apache (e.g. PHP version, your web applications), it may not be>apache's fault.The PHP version got upgraded from 4.4.0 to 4.4.6 too, but none of the actual application scripts changed.BTW: At times what one sees happening is that 2 of the httpd daemons quickly go up to (each, or in turn) about 50% (or 70% if it can grab that much), then stays quite a while at that, and then goes back to a more reasonable amount.
You'll have to correlate this with HTTP requests apache receives - maybe there's a PHP script that's unusually CPU intensive.
Meanwhile: I'm still open for suggestions as to how to best make Apache behave less selfishly.
You may try playing with login.conf(5) (see "resource limits"), but do it on a spare machine first :)
Also, you may try scaling down the number of processes Apache is allowed to create (at the possible expense that some clients get an error message instead of a page).
Still, if the performance was OK before you switched to Apache2, my bet would be that something changed in PHP or your scripts, not in Apache.
signature.asc
Description: OpenPGP digital signature
