httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Wed, 19 Sep 2001 21:03:13 GMT
On Wednesday 19 September 2001 01:49 pm, Aaron Bannert wrote:
> On Wed, Sep 19, 2001 at 12:18:31PM -0700, Ryan Bloom wrote:
> > On Wednesday 19 September 2001 12:11 pm, Aaron Bannert wrote:
> > > So I have two questions:
> > >
> > > 1) How do we send back that error?
> >
> > You can't.  There is no way to determine how busy the other processes
> > are.
> 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.

> > > 2) How long should the queue be? Should we just set some arbitrary
> > > constant, defined in mpm_default.h, or should we come up with some
> > > heuristic?
> >
> > Manoj actually ran tests about this back when we were using the
> > apache-apr repository.  In his tests, the optimal length was equal to the
> > number of threads. Having a bit of wiggle room just didn't get us
> > anywhere.
> Sounds reasonable. It's just a tradeoff:
> 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.

Ryan Bloom
Covalent Technologies

View raw message