httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: cvs commit: httpd-2.0/server/mpm/worker worker.c
Date Wed, 19 Sep 2001 19:50:42 GMT
Aaron Bannert <> writes:

> On Wed, Sep 19, 2001 at 06:47:31PM -0000, wrote:
> > trawick     01/09/19 11:47:31
> > 
> >   Modified:    server/mpm/worker worker.c
> >   Log:
> >   if we're gonna trash the connection due to a queue overflow, at the
> >   very least we should close the socket and write a log message (mostly
> >   to aid debugging, as this is a showstopper problem)
> >   
> >   this is no fix; there is a design issue to consider; hopefully this
> >   will
> [I assume you had more to say?]

I forgot what the rest of the sentence was :)  I intended to follow up
here anyway, but in my rush home to beat the school bus you chimed in

> Now that the queue represents the number of accepted-but-not-processed
> sockets, it does not necessarily need to be the size of the number of
> threads, but instead some other value that indicates the number of
> sockets we'll accept before sending back some "Server Busy" error.
> So I have two questions:
> 1) How do we send back that error?
> 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?

Let's pick a number for now for the length of the queue.  As far as I
am concerned, the current number is a reasonable starting point.

It shouldn't be too low, since when the server is busy we want to
always have some available work when workers are done processing a
previous connection.

It shouldn't be too high because

1) the queue may be full because our workers are busy, and for all we 
   know there is another httpd process with workers which aren't busy,
   and we shouldn't be accepting too many new connections because that
   keeps the idle workers in another process from processing them;
   with a larger queue we have higher risk of starving workers in
   another process even though we can't do anything ourselves
2) (not terribly important to me) any connection sitting in the queue
   at graceful restart time is a connection which could have been
   processed with the new configuration but won't be since we were
   needlessly greedy

If we avoid calling accept when our queue is full, we should fix this

So what to do?

query state of queue before accept (without getting a lock if
possible)...  if pretty full*, instead of calling accept() block in a mutex
which will be posted by a worker when get go above some threshhold of
available slots in the queue

*maybe some lack of exactness here can allow us to avoid a lock
Jeff Trawick | | PGP public key at web site:
             Born in Roswell... married an alien...

View raw message