Hi,
I have just commited some significant improvements in how MPM reacts
when it runs out of workers (sorry for the big diff). If the number of
connections of a process is above
threads_per_child + WORKER_OVERCOMMIT * (idle_workers - 1)
or if all workers are busy, we don't accept new connections in that
process. Such a dynamic connection limit is necessary because we may
have both async and non-async (ssl) connections.
WORKER_OVERCOMMIT is fixed at 2 at the moment, but should of course be
a config option. I think this may already be enough to tune MPM event
to some specific setup. For example, the value 2 seems ok if the
server serves some large files to slow clients, i. e. the workers will
block for some time during write completion because of disk seeks. If
a server mainly serves small files or has all files in RAM, a larger
value may be better. Does anyone have a suggestion for a good name for
this option? AsyncWorkerThreadFactor?
Speaking about config options, I think that MaxClients should be
renamed to MaxWorkers, because it limits the number of worker threads,
not the number of clients. As with the MaxRequestsPerChild ->
MaxConnectionsPerChild rename, we would still accept the old name with
a warning. Thoughts?
There are still quite a few improvements possible in the mpm event
code, but I don't think any of these are blockers for the next beta:
- It is still possible to stall async connections by making lots of
ssl connections to that process. Probably a process should always keep
one worker in reserve for async work.
- Sometimes, the state 'C' is not cleared in the scoreboard after the
connection is closed.
- I think connection_count doesn't need to be accessed atomic anymore.
- Probably a lot of other optimizations.
Cheers,
Stefan
