From owner-freebsd-net Sun Jul 25 10:34:48 1999 Delivered-To: freebsd-net@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 47B7F151A5 for ; Sun, 25 Jul 1999 10:34:40 -0700 (PDT) (envelope-from aron@cs.rice.edu) Received: (from aron@localhost) by cs.rice.edu (8.9.0/8.9.0) id MAA04788; Sun, 25 Jul 1999 12:33:59 -0500 (CDT) From: Mohit Aron Message-Id: <199907251733.MAA04788@cs.rice.edu> Subject: Re: FreeBSD tuning for webserver performance To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Sun, 25 Jul 1999 12:33:59 -0500 (CDT) Cc: freebsd-net@freebsd.org In-Reply-To: <199907242210.AAA01871@labinfo.iet.unipi.it> from "Luigi Rizzo" at Jul 25, 99 00:10:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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. > > If you are sending so much data to fill your 50-slot queues (and this > can only be because of a burst) you do want drops so that you get > immediate feedback and can de-synchronize the flows and avoid further > bursts of the same kind. > 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 in short succession. At least for benchmarking Apache, I have to setup more than 50 clients connecting simultaneouly to it before the server gets saturated. 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 with SYN/ACK packets, it would only amount to about 40K of data and not 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. For the above reasons I'm not convinced that the output queues would be flooded with 1500 byte packets. However, if it is indeed a concern, then perhaps the solution is to use different values for the input and output interface queue lengths. The IP queue can have a larger length (say 1000) while the interface output queues can remain at 50. - Mohit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message