Date: Sun, 25 Jul 1999 23:39:26 -0500 (CDT) From: Mohit Aron <aron@cs.rice.edu> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD tuning for webserver performance Message-ID: <199907260439.XAA11549@cs.rice.edu> In-Reply-To: <199907260053.CAA03166@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jul 26, 99 02:53:01 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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! > Well, actually I found the value of 50 too small for experiments. I've been using the value of 1000 and find no problems with it - however the increase can 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. > 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 ? > I've measure this on a 300MHz Pentium II running FreeBSD-2.2.6. SYN processing takes about 140 usec. This isn't very surprising considering the amount of state that gets initialized - inpcb, tcpcb, socket, route structure to client etc. If connection establishment overhead takes so much time, the IP queue can certainly overlow with bursts of SYN packets. > > 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 (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. - Mohit 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?199907260439.XAA11549>