Paul Querna wrote:
This is traditionally called the 'Thundering Herd' Problem.
When you have N worker processes, and all N of them are awoken for an
accept()'able new client. Unlike the prefork MPM, N is usually a smaller
number in Event, because you don't need that many EventThreads Per
Number of WorkerThreads,
I'll buy that. you only need 2 processes to deal with 3rd party module reliability
worries. not much of a herd. if you have reliable code and we scale well enough to
handle the traffic, nothing stops you from using one process.
I also reason that on a busy server, the place you most likely want to
put the event mpm, you will have many more non-listener sockets to deal
with, and those will fire more often than new clients are connecting,
sure, assuming that there are typically multiple HTTP requests per connection or big
files/slow network combinations to trigger Brian's async write logic.
meaning you will already be coming out of the _poll() with 'real'
events. So the 'cost' of being put into the Run Queue isn't a 'waste',
like it is on the Prefork MPM, where you just would go back into _poll()
without having done anything.
I'll buy that too. once the poll pops, there is a loop to consume all of the poll events
in one go. judging by the comments in worker.c::listener_thread, I think Manoj meant to
do that in worker's ancestor but never got a round tuit.
Greg
