httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: application level accept() filter for 1.3.x
Date Tue, 19 Dec 2000 13:23:37 GMT
Hey Theo,
Cool stuff! This handles the case of the client establishing the initial
connection then waiting to send data; I would think the more common case is a
client starting a connection, sending the first request immediately. This
causes the server to do an accept followed by a read which should return data.
The request is serviced then if keep-alives are enabled, the server does
another read. This read is the one that has the potential to block for long
periods of time.

Have you ever used the kqueue/kevent API on FreeBSD?


> I know that people "don't care about advancements to 1.3.x".  With that
> I thought that this would be at least interesting enough to post here even
> it isn't used by anyone.  This is a patch that applies to 1.3.12 and 1.3.14.
> Problem:
>   Clients connect to Apache and spend an awfully long time sitting before
> make their request.  This ties up children so that they cannot answer other
> requests.  Many people turn off KeepAlives because they don't seem to have
> enough children slots to serve all of the "concurrent" connections.  This is
> well understood issue.
>   The client can still waste "child slot time" between the connect() and
> write() of the request, which is between the accept() and read() on the
> side.  Why read() when there is nothing there?  Actually, in the particular
> case of Apache, why even accept() when there is nothing to read()?  In BSD
> there is a kernel modification that augments accept() to *not* return to the
> application until there is data available to be read() by the program that
> accepting()ing.
>   This OS level solution is not easy to implement under Linux or Solaris.
> Solution:
>   Create a parent process that is responsible for all accept()ing.  That
> process only passes those accept()ed file descriptors to Apache children
> processes once they have data available for read()ing.  This passing is done
> via IPC over unix domain sockets.  At most two additional context switches
> incurred with this model, but it allows hundreds of "slow" inbound
> to occur without unnecessarily tying up Apache children processes.
>   The patch was written to work with a 1024 filedescriptor fdsetsize -- it
> uses select().  It also limits the number of accept()ed connection that have
> not been handed off to Apache children to 700.  These numbers are hardcoded
> because, for my own reasons, it was ideal *not* to modify the httpd.conf on
> the systems I wrote this for.
>   I have tested this on Linux 2.2.17 and it seems to work well.
>   The patch is changes the flow of accepting new client connections and adds
> one process to the run-time.  There is currently a problem gracefully
> restarting the httpd instance and stopping it with the apachectl program --
> but I never do that anyway.  Someone with more interest than myself can fix
> that :-P
>   The patch is available at  It is
> the fifth item under "Apache related projects."
> I would love people's input!!!  I am sure there are other people suffering
> from the same sort of problem.
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E  2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7

View raw message