httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Korthof">
Subject Re: Apache 1.2b7-dev performance
Date Fri, 07 Feb 1997 19:48:28 GMT
On Feb 6, 10:56pm, Marc Slemko wrote:
> Subject: Re: Apache 1.2b7-dev performance

> There is already some description of lingering_close() on the
> misc/fin_wait_2.html page; when I figure out how I need to explain more I
> will add it there.
> I'm not sure that recommending disabling it for a performance gain is a
> good idea.  Note that the performance loss from using it should be
> completely gone when Apache is threaded; at least using the model RST
> implemented.

Well, yes, once Apache is threaded it shouldn't be a problem.  But Apache isn't
yet threaded, and won't be until 2.0.  Seeing as we're working off 1.2, and
this is potentially a bottleneck, it should be mentioned.

> Did you try just replacing the timer it uses so instead of hard_timeout()
> it sets one for 15 seconds or so?  The only reason there should be any
> performance loss is because of children hanging around for longer.  If the
> OS properly supports SO_LINGER, that should be able to be used instead
> without the performance hit.
>-- End of excerpt from Marc Slemko

Well, I'm willing to play with this, but SO_LINGER doesn't work on many
platforms, so the issue remains.

The children spending extra time on the request is the problem I'm seeing.  The
server where this is occuring servers a high load; during peak demand, it
servers over 60 requests per second.  It has a fast CPU, but limited memory: at
most, we can have 175 children running.  We can't put the KeepAliveTimeout much
higher than 3 seconds, since otherwise that ties up too many children.

With KeepAliveTimeout at 3 and w/o NO_LINGCLOSE, Apache 1.2b7-dev maxes at 60
r/s.  Apache 1.1.3 can handle at least 67 r/s, with capacity to spare; Apache
1.2b7-dev w/o NO_LINGCLOSE can also handle more than 65 r/s with capacity to
spare (I haven't seen it go higher, mostly because demand has diminished
somewhat since I tested with 1.1.3).

So I'm looking at at least a 10% increase in capacity, and based on the number
of spare servers, probably more like 20%.  That's significant.

However, while testing I realized that there is a far more extreme scenario.
 If we had only 125 children running, w/o NO_LINGCLOSE, 1.2b7-dev can't quite
handle 40 requests/second.  Both 1.1.3 and 1.2b7-dev with NO_LINGCLOSE can
handle 60 requests/second.  That's a 50% performance improvement; admittedly,
it is under highly specialized circumstances (fast CPU, low memory), but there
are likely to be others running high performance sites under similar
situations.  And if they switch from 1.1.3 to 1.2 and see that kind of drop in
performance, they're not going to be happy.

Further, adding more children doesn't entirely solve the problem since there
remain additional costs to context switching.  Ideally, for a high performance
site, you want Apache to handle the request quickly and move on to the next one
ASAP; lingering_close slows that process down.  Still, for machines with lots
of memory, which can afford to have lots and lots of children, NO_LINGCLOSE
will probably offer significantly less of a performance improvement.

I realize there are potential problems with NO_LINGCLOSE, but with appropriate
timeouts & good observation, it will legitamitely improve performance for high
load sites.  So I think we should suggest it as one possible performance
improvement, with a warning about potential problems with FIN_WAIT_2 (and other

     -- Ed Korthof        |  Web Server Engineer --
     --    |  Organic Online, Inc --
     -- (415) 278-5676    |  Fax: (415) 284-6891 --

View raw message