httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Saju Pillai" <>
Subject Re: Event MPM accept() handling
Date Wed, 01 Mar 2006 15:45:26 GMT
On 01/03/06, Paul Querna <> wrote:
> Greg Ames wrote:
> > Saju Pillai wrote:
> >
> >> I can understand why serializing apr_pollset_poll() & accept() for the
> >> listener threads doesn't make sense in the event-mpm.   A quick look
> >> through the code leaves me confused about the following ...
> >  >
> >>  It looks like all the listener threads epoll() simultaenously on the
> >> listener sockets + their private set of sockets added to the pollset
> >> by workers.
> >
> > looks like you are correct.
> >
> > originally there was a separate event thread for everything but new
> > connections and the listener thread's accept serialization was the same
> > as worker's.  then it seemed like a good idea to merge the listener and
> > event threads, and it only supported a single worker process briefly.
> > since there was only one merged listener/event thread in the whole
> > server there was nothing to serialize at that time.  then a few of us
> > grumbled about what happens if some 3rd party module seg faults or leaks
> > memory and we went back to multiple worker processes.

Can you tell us what was the reasoning behind merging the event thread and
the listener thread ? A seperate event thread implies that the listener
threads could serialize for accept() for platforms that need serialized
accept(). The event thread never needs to accept() - it only needs to check
for read/write/close events.  ( or the platforms that event mpm runs on -
don't need serializing of accept ?)


> >>   Will apr_pollset_poll() return "success" to each listener if a new
> >> connection arrives on a main listener socket ? If so won't each
> >> listener attempt to accept() the new connection ?
> >
> > I think so, but I'm not a fancy poll expert.  Paul?
> Correct. This is on Purpose.  It actually turns out to be faster to call
> a nonblocking accept() and fail than it is to use the AcceptLock() that
> the other MPMs do. (Micro benchmarks I did back then seemed to show
> this, and just hammering a machine and comparing the results for Worker
> & Event MPMs seem to indicate this too).
> > then the question is how bad is it?
> Not that bad :)

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 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,
> 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.
> -Paul

View raw message