Date: Mon, 26 Jul 1999 02:53:01 +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: <199907260053.CAA03166@labinfo.iet.unipi.it> In-Reply-To: <199907251733.MAA04788@cs.rice.edu> from "Mohit Aron" at Jul 25, 99 12:33:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907260053.CAA03166>