httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Heidemann <jo...@ISI.EDU>
Subject Re: performance ``bugs'' in apache-1.1b4's P-HTTP
Date Thu, 11 Jul 1996 00:27:18 GMT
On Wed, 10 Jul 1996 19:01:52 EDT, Robert S. Thau wrote: 
>One thing which it would be helpful to know is how much the second
>tweak to the server (disabling the Nagle algorithm) helps on its own
>(and whether it does anything at all, perhaps by allowing the window
>to open up a bit wider, to cure the effects of problem one, the MIME
>header partial packet --- probably not, I know, but perhaps it's worth
>asking).

I believe that the first problem causes a delayed-ack stall when
opening the congestion window at the beginning of a P-HTTP request
when the connection window is <= 2 segments.  The second problem
causes a delayed-ack stall at the end of a P-HTTP request when packet
lengths meet the restrictions described in the paper.
Either stall costs ~100ms (on average).  (In my tests, it actually
costs ~170ms consistenly because the client and server sync on the
delayed ack timer.)

If my analysis is correct, than the Nagle algorithm is not involved in
the first problem.  It's a congestion window problem.  In this case,
fixing only the second problem should leave the first stall and a
~100ms performance hit whenever the connection window must open from
<= 2 segments.  For people connecting at >=128Kbps speeds this cost
begins to be noticable (for the workload I give).  At slower speeds
than this the stall will be lost in transfer time.

Alexei Kosut wrote:
>... Unfortunately, Netscape Navigator has a rather serious bug in its
>Keep-Alive implementation - if the end of the file is in the same read as
>the headers, it will not recognize properly that it is dealing with a
>persistent connection, and the connection will hang, waiting for a close.
>
>... One
>option is, I suppose, to only do the fflush() for files less than whatever
>Netscape's read buffer size is (I tested for this a couple month ago when
>I first wrote the keep-alive code, but I now forget - it was 256 or
>1024 bytes, or something of the sort).

If Alexei's description of the Netscape problem is correct, than his
proposed work-around (find the buffer size and only flush for files
smaller than that) sounds ideal.

What versions of Netscape exhibit the problem?  If they include 2.x
(i.e., any non-beta versions), then Apache certainly must work around
the problem.  If the problem occurs only in 3.0bX versions (for X < 5)
then it might be feasible to tell people to upgrade.  (People using
betas are presumably motivated and knowledgeable enough to upgrade,
while most people use production software and won't upgrade unless you
put a gun to their head.)

Another option would be to have Apache detect browser versions and
work-around the bug only when necessary.  It seems a shame to clutter
up Apache with such code, but it may be a reasonable engineering
solution.

   -John Heidemann
    USC/ISI


Mime
View raw message