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 [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
