httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@apache.org>
Subject Re: Event MPM accept() handling
Date Wed, 01 Mar 2006 16:11:31 GMT
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

Mime
View raw message