From owner-freebsd-net Sun Jul 25 20:20:26 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 1752514CF8 for ; Sun, 25 Jul 1999 20:20:10 -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 CAA03166; Mon, 26 Jul 1999 02:53:02 +0200 From: Luigi Rizzo Message-Id: <199907260053.CAA03166@labinfo.iet.unipi.it> Subject: Re: FreeBSD tuning for webserver performance To: aron@cs.rice.edu (Mohit Aron) Date: Mon, 26 Jul 1999 02:53:01 +0200 (MET DST) Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <199907251733.MAA04788@cs.rice.edu> from "Mohit Aron" at Jul 25, 99 12:33:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2253 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > this one i'd be a bit careful about. The same parameter is used > > for both input (ipqmaxlen = IFQ_MAXLEN) and output queues. On the output > > side this means you can have up to 1.5MBytes queued on output on one > > interface -- that's over one second on a 10Mbit ethernet. ... > The burst might result from SYN packets sent by clients. I don't find it > inconceivable that a busy webserver often gets more than 50 connection requests understand your point about SYN's, and the need to increase the input queue length (and maybe the out queue) a bit, but you are proposing a 20fold increase! But my point is, i assume a fast machine is able to process input packets (such as SYNs) at wire speed hopefully so there shouldn't be any significant queueing of these (i'd be glad to be corrected if you have actual data showing that queues of SYNs do build up). > Even on an input burst of this kind, I don't expect that the output queues > would be flooded because TCP takes quite a while (about 150 usec) to setup the > connection and respond with a SYN/ACK. Even if the output queues get flooded hmm... this is quite a bit of time. how did you measure this and on what hardware ? > 1.5MB. On the other hand, the output queues can only be filled with 1500 byte > data packets if the webserver somehow does writes in quick succession across > several connections. Such synchronization however seems unlikely because > the code path for the webserver involves reading the file, checking for > validity etc. 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. 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