You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1998/01/11 00:48:30 UTC
interesting bug with zb and Nagle and FreeBSD and lo0
---
Server: Apache/1.3b4-dev
Document Length: 1316
Concurency Level: 1
Time taken for tests: 10.060 seconds
Complete requests: 51
Failed requests: 0
Keep-Alive requests: 51
Bytes transfered: 81448
HTML transfered: 67116
Requests per seconds: 5.07
Transfer rate: 8.10 kb/s
Connnection Times (ms)
min avg max
Connect: 0 0 0
Total: 56 197 201
---
We kick ass! 5 requests per sec using keepalives on a p166 getting a ~1k
document.
Quite interesting, since getting / instead of /index.html gets 2 order of
magnitude better rates.
Looking further:
# request
16:24:45.303916 localhost.worldgate.com.3310 > localhost.worldgate.com.http: P 437:537(100) ack 6390 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92000> (DF)
# ack (200ms!)
16:24:45.502068 localhost.worldgate.com.http > localhost.worldgate.com.3310: . ack 537 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92001> (DF)
# request
16:24:45.502122 localhost.worldgate.com.3310 > localhost.worldgate.com.http: P 537:546(9) ack 6390 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92000> (DF)
That makes it more obvious. We have delayed ack acting on the server
delaying the ack for 200ms, and Nagle working on the client preventing
it from sending the end of the request until it gets the ack. This gives
almost exactly 5/sec.
The fix is to change zb to disable Nagle, but I am confused about WTF
FreeBSD is generating two packets. Heck the mtu of lo0 is 16k.
The same thing happens if I send across the network to another machine
from this one. It comes from a single write() and 109 bytes isn't
that much. It does this 100% of the time.
Re: interesting bug with zb and Nagle and FreeBSD and lo0
Posted by Marc Slemko <ma...@worldgate.com>.
As someone pointed out to me, this is section 14.11 of TCP/Ill vol3. For
writes between 101 and 208 bytes, it is split into two mbufs instead of
one mbuf cluster. The problem is that the TCP output routines send each
mbuf in a seperate packet.
Changing MINCLSIZE to 101 from 208 fixes this and doesn't look like there
are too many bad side effects.
On Sun, 11 Jan 1998, Marc Slemko wrote:
> Looking further, this odd behaviour happens on any write larger than
> the size of one mbuf (100 bytes) but that will still fit in to
> (208 bytes). My guess is some boundry condition isn't being
> checked properly...
>
> Wonder if other BSD stacks suffer.
>
> On Sat, 10 Jan 1998, Marc Slemko wrote:
>
> >
> > # request
> > 16:24:45.303916 localhost.worldgate.com.3310 > localhost.worldgate.com.http: P 437:537(100) ack 6390 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92000> (DF)
> > # ack (200ms!)
> > 16:24:45.502068 localhost.worldgate.com.http > localhost.worldgate.com.3310: . ack 537 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92001> (DF)
> > # request
> > 16:24:45.502122 localhost.worldgate.com.3310 > localhost.worldgate.com.http: P 537:546(9) ack 6390 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92000> (DF)
>
Re: interesting bug with zb and Nagle and FreeBSD and lo0
Posted by Marc Slemko <ma...@worldgate.com>.
Looking further, this odd behaviour happens on any write larger than
the size of one mbuf (100 bytes) but that will still fit in to
(208 bytes). My guess is some boundry condition isn't being
checked properly...
Wonder if other BSD stacks suffer.
On Sat, 10 Jan 1998, Marc Slemko wrote:
>
> # request
> 16:24:45.303916 localhost.worldgate.com.3310 > localhost.worldgate.com.http: P 437:537(100) ack 6390 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92000> (DF)
> # ack (200ms!)
> 16:24:45.502068 localhost.worldgate.com.http > localhost.worldgate.com.3310: . ack 537 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92001> (DF)
> # request
> 16:24:45.502122 localhost.worldgate.com.3310 > localhost.worldgate.com.http: P 537:546(9) ack 6390 win 57344 <nop,nop,timestamp 135124 135124,nop,nop,cc 92000> (DF)