httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Wed, 19 Sep 2001 21:32:47 GMT
On Wed, Sep 19, 2001 at 02:03:13PM -0700, Ryan Bloom wrote:
> On Wednesday 19 September 2001 01:49 pm, Aaron Bannert wrote:
> > I'm not sure if simply closing the socket is the right answer either.
> > Is there a more appropriate error code? "Server Temporarily Unavailable"
> > or whatnot?
> >
> > I'd agree that we can never know if the server is truly overloaded,
> > but with a sufficiently long queue and an assumed random distribution
> > of requests to the children, I'd say "Server Busy" is pretty close to
> > the truth. It is definately the truth for that particular child.
> You shouldn't ever be in this situation.  This is why the queue_full condition
> existed to begin with.  Basically, the listener should stop listening if it doesn't
> have enough workers to handle a connection.  If we are putting requests in
> the queue without a worker to handle it immediately, then we take the very real
> chance of starving that request.

Well, in that case I think I'll have to put that other condition back in
again. I see now why it was necessary.

But isn't it true that even with the not_full condition, you can be
in a state where each worker is off servicing a request, and your
queue is full (The listener is blocking on that not_full condition).
Let's say that at that point the server does a graceful restart.
The workers will happily finish their connections, but they will
exit their loop and die before checking the queue. That is the same
situation we're in right now, where it is possible for N already
accepted sockets to be the queue with no workers to service them.
(I trust you'll correct me if I'm wrong here)

> > longer queue ==> higher first-byte latency, more accepted sockets
> > spontaneously die when we do a graceful restart. better tolerance to
> > request spikes.
> We should NEVER kill a request during a graceful.  This problem goes
> away if we stop accepting connections when we don't have a worker to
> handle it.


> > shorter queue ==> lower first-byte latency, less sockets mercilessly
> > killed, less tolerant to request spikes.
> >
> > I doubt it will have a significant enough impact in the general case to
> > warrant a runtime parameter, but I'll definately consider a compile-time
> > definition (or at least something to override the default of
> > threads_per_child).
> Manoj and I originally thought that we could add a few extra spots to the
> queue, so that as a worker finished, there was something for it to grab and
> work on immediately.  In Manoj's tests however, this ended up not really 
> helping us at all.

The fast-path comes from when the worker thread checks the queue for
non-emptyness. Consider a server where all workers are off servicing
requests. At first the queue is empty, but as it fills up and workers
return, they do not need to call cond_wait(), since there already is
a socket waiting for them.


View raw message