httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject MPM-Event, renaming MaxClients, etc.
Date Sun, 19 Jun 2011 12:49:31 GMT

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.


View raw message