On Wednesday 19 September 2001 02:32 pm, Aaron Bannert wrote:
> 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)
The workers should check the queue before they die. If they do that,
then we won't drop any connections at all.
> > > 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.
Agreed that this is the goal, but the problem is the potential starvation
when all threads are serving long-lived requests.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
