httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
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?

Bill

> I know that people "don't care about advancements to 1.3.x".  With that
said,
> I thought that this would be at least interesting enough to post here even
if
> 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
they
> 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
a
> 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
server
> 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
is
> 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
are
> incurred with this model, but it allows hundreds of "slow" inbound
connections
> 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 http://www.lethargy.org/~jesus/projects/.  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
>


Mime
View raw message