From owner-freebsd-net Sun Jul 25 22:52:57 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id E56D3152C2 for ; Sun, 25 Jul 1999 22:52:45 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA03377; Mon, 26 Jul 1999 05:28:24 +0200 From: Luigi Rizzo Message-Id: <199907260328.FAA03377@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Mon, 26 Jul 1999 05:28:24 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <199907260439.XAA11549@cs.rice.edu> from "Mohit Aron" at Jul 25, 99 11:39:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2865 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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