httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
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
______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message