httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: [PATCH] convert worker MPM to leader/followers design
Date Thu, 11 Apr 2002 19:34:29 GMT

> "Bill Stoddard" <bill@wstoddard.com> writes:
>
> > > Right, the problem is that the listener needs to avoid doing the
> > > accept if the queue is full.
> > >
> > > That part is easy: add a "block_if_queue_full()" method on the
> > > fd_queue class, and have the listener call it before doing an
> > > accept.
> > >
> >
> > I am not an expert on the worker MPM but I don't think that is an accurate statement
of
> > the problem.  The accept thread uses ap_queue_push() to enqueue a socket for the
worker
> > threads. ap_queue_push() will block if the queue is full.
> >
> > The problem is that the queue can be EMPTY even when all the worker threads are
busy
> > handling connections.  The way the code is today, the queue can hold
ap_threads_per_child
> > elements. Now consider 2 x ap_threads_per_child connections comming into the server
at
> > once.. The first 1 x ap_threads_per_child connections will be accepted and handled
by
the
> > worker threads. The next ap_threads_per_child connections will get queued and this
is
> > precisely the problem...
>
> That is the problem I thought was being dealt with originally...
> After seeing it stated differently a couple of times I figured I was confused.
>
> probably-stupid idea:
>
> Maybe a counter of blocked threads can be cheaply maintained within the
> existing serialization.  The listener can use this to decide if it
> should call accept() or give up the CPU.
>
> But this bites
>
> 1) when there is just one child process (wasted syscall)
>
> 2) because it would normally go faster if the listener could stay just
>    ahead of the workers so that workers can dequeue new work when they
>    finish with the old without having to wait on the listener to
>    enqueue something
>
> --
> Jeff Trawick | trawick@attglobal.net


Sounds like a reasonable solution. I doubt you could measure the performance difference
due to a wasted syscalls.  And you can always play some games with the counters to enable
you to accept a few additional connections (however you define 'few') in order to keep
some work in the queue.

Bill


Mime
View raw message