Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Jul 1999 05:28:24 +0200 (MET DST)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        aron@cs.rice.edu (Mohit Aron)
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: FreeBSD tuning for webserver performance
Message-ID:  <199907260328.FAA03377@labinfo.iet.unipi.it>
In-Reply-To: <199907260439.XAA11549@cs.rice.edu> from "Mohit Aron" at Jul 25, 99 11:39:07 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> certainly be lesser. The number should be as large as the maximum burst that a
> busy webserver is willing to tolerate - the number 50 seems rather small.

i fully agree on the need of an increase for the input queue, just how
much i am not sure...

The data on SYN processing is interesting but really seems a large one!

May i ask you how did you measure them -- by instrumenting the code
paths, or looking on a tcpdump at the delay between a SYN request
on the wire, and the SYN|ACK response. In the latter case, was
there any other traffic generated by the server ?

A quick experiment locally on a K6-400 w/ 100mbit card (de)
running tcpdump shows that there are about 40us between the ping
request and response, and some 90-100us between the SYN and the
corresponding ACK (this at the bpf level).
So the SYN processing overhead appears to be more in the 50us range,
the rest being generic packet processing overhead.
Surely worth some optimization, though...

> ...
> > i think this kind of behaviour is very likely as at times (generally when
> > the window suddenly opens e.g. because of recovered losses) you have a
> > burst which can even be large (e.g. some 10-20 packets)  and your data
> > are already queued in the socket buffer.
> 
> Yes, but I still don't see why you think dropping these packets at the driver
> is a good idea. The CPU has already expended work to process these packets 

because you get an immediate notification (check tcp_output() -- an
error generates a tcp_quench()) reducing the window to a single segment
and avoiding further congestion and occurrence of such events (and
you already have a full window in transit so there is no performance
penalty for your connection -- as ACK come in the window reopens
to its full size).

Keeping queues short is always useful -- even in the case of your
busy web server, just to give one example, you might cause your
SYN|ACK for new connections incur a large delay just because you
have a huge number of data packets queued for delivery.

> (computing checksums and initializing all the headers). If anything, this 
> particular problem should be fixed by making sure TCP never sends bursts - 
> rather than dropping packets from such bursts by limiting the interface 
> queues. 

unfortunately fixing TCP like you suggest, while desirable is not
easy because there is not a fine-grained timer to use.

	cheers
	luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, luigi@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)

		  http://www.iet.unipi.it/~luigi/ngc99/
====  First International Workshop on Networked Group Communication  ====
-----------------------------------+-------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907260328.FAA03377>