httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven B <ste...@teamholistic.com>
Subject FCGID: Changes in behaviour of DefaultMaxClassProcessCount/FcgidMaxProcessesPerClass negatively impacting shared hosting providers
Date Wed, 14 Apr 2010 01:31:16 GMT
Somehow there was a decision made that changed max PHP processes from
per-user to per-vhost between the old mod_fcgid and the newer 2.3.5 version.

This is really affecting us on servers where we had a nice simple way to say
"users shall have X PHP processes and no more!" but now with the update to
2.3.5 it becomes modified with "times the number of vhosts you have"

There needs to be some kind of replacement directive here somewhere. The
ability to limit people to a set number of spawned PHP processes based on
user ID is very valuable to control resource usage and this has been blown
away.

Also this introduces another problem related to what happens when something
happens which may cause the server to slow down a little. If one for example
has 50 people on one server, each running 10 vhosts, and have a maxprocess
count of 3. Under the old system you would be limited to the server spawning
150 PHP processes. Okay so that sucks, but it can be handled and the server
catches up or a watchful eye or script comes in and massages out the kinks.
Under the new method you now have the server spawning 1500 PHP processes.

I'm sure that example has lots of holes and might not be the best.

But we really need to get back a way to put a limit on PHP processes by
user. This per-vhost thing might be great in theory or for people who can
exercise an iron fist of control on their servers, but for people running
shared servers trying to sell a product and be competitive this change just
blows the lid off of one of the most valuable resource/user controls that we
had.

The real life affect is users more able to impact others and an increase of
10-20% in committed memory for all these extra PHP processes. So far we've
been able to counteract this a little by tightening up (a little too tight)
the idle timeouts on the processes above the minimum but this then impacts
CPU.

Or I don't know, maybe I'm missing something?

Steve

Mime
View raw message