httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Jim Gettys)
Subject Re: Apache 2.0/NSPR
Date Thu, 10 Sep 1998 15:37:22 GMT

> Sender:
> From: Simon Spero <>
> Date: Thu, 10 Sep 1998 01:46:21 -0400 (EDT)
> To:
> Subject: Re: Apache 2.0/NSPR
> -----
> yeah-i would have said that if my head worked better at the moment. this
> fits in o the send side buffer management.
> simon
> On Wed, 9 Sep 1998, Dean Gaudet wrote:
> >
> >
> > On Thu, 10 Sep 1998, Simon Spero wrote:
> >
> > > 7) TCP changes: There are several changes that would be useful for a web
> > > server.
> >
> > You forgot:
> >
> > 7.n) Get rid of Nagle, and get rid of auto-flush-on-write().  Allow the
> > app to tell the kernel when it's at the end of what it's sending...
> > there's no need for silly timers and that crud like in Nagle when the app
> > is well behaved.
> >
> > Dean
> >

Yes, turn off Nagle once you do your own buffering...

I did have a conversation with a TCP wizard  (can't remember if
it was Van, or possibly Greg Minshall) at SIGCOMM a year ago though: 
the problem with Nagle may not be exactly what we thought and say
in our SIGCOM paper...  

A properly done Nagle implementation may not in fact be slowing down the 
connections; but what does happen is that the "every other packet" ack 
policy implemented by most TCP's interacts with Nagle, such that if it 
is an odd packet, you get a major delay at the END of a conversation (the 
application has flushed, but the OS holds onto the data).

The comment of this wizard was that the every other packet acking 
optimization in TCP has been a lose (you get poorer  clocking of data, 
and possibly slower slow start behavior than if every packet is acked).

We tried to get a final verdict on exactly what is causing the observed
delays in our TCP dumps from Van Jacobsen, but he's never gotten back
to us, and the effect is the same: Nagle should be disabled in any
case, and isn't needed once you have sane buffering, flushing and
timeouts at a higher level where you know more.
			- Jim

View raw message