William A. Rowe, Jr. wrote:
Yes it makes sense. But I'd encourage you to consider dropping that
keepalive time and see if the problem isn't significantly mitigated.
It is mitigated somewhat, but we still hit maxclients without our "hack"
in place.
Right now, it does take cycles to walk the
scoreboard to determine the number in a given state (and this is
somewhat fuzzy since values are flipping as you walk along the
list of workers.)
I know the worker MPM, for example, keeps a count of idle workers
internally. Maybe just an mpm query to retrieve that value would be
good? all MPM's keep track of this in some fashion because they all
know when maxclients is reached.
Adding an indexed list of 'counts' would be
very lightweight, and one atomic increment and decrement per state
change. This would probably be more efficient than walking the
entire list.
Sounds good. Of course, when changing from on state to another you
would always have to decrement the previous state and increment the new
one. The way the core seems to be now, that would require some careful
examination of the code to ensure all the state changes were covered.
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
