From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 09:27:06 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EE1116A4CE for ; Mon, 9 Feb 2004 09:27:06 -0800 (PST) Received: from dragon.rutgers.edu (dragon.rutgers.edu [128.6.25.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B89743D1F for ; Mon, 9 Feb 2004 09:27:06 -0800 (PST) (envelope-from bohra@cs.rutgers.edu) Received: by dragon.rutgers.edu (CommuniGate Pro PIPE 4.1) with PIPE id 11624664; Mon, 09 Feb 2004 12:27:03 -0500 X-Spam-Status-LCSR: dragon spam scanned Received: from [128.6.171.146] (account bohra HELO cs.rutgers.edu) by dragon.rutgers.edu (CommuniGate Pro SMTP 4.1) with ESMTP id 11624657; Mon, 09 Feb 2004 12:26:35 -0500 Message-ID: <4027C26A.4090609@cs.rutgers.edu> Date: Mon, 09 Feb 2004 12:24:58 -0500 From: Aniruddha Bohra User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031024 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <1076342789.b793fb20dkt@digitalme.com> <20040209110108.R43036@odysseus.silby.com> In-Reply-To: <20040209110108.R43036@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on spamfilter.rutgers.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 cc: freebsd-hackers@freebsd.org cc: Dung Patrick Subject: Re: [call for helpers!] Tuning for the Beaver Challenge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 17:27:06 -0000 Hello, > The one setting that I do suggest you keep is: > > kern.ipc.somaxconn=512 (128 may be too low for http testing) In our experience with Apache and clients that do not use Keep Alive (are short lived), 512 is also very low. It causes listen queue overflows and leads to a very low throughput. Another place that we had to look at was the IP sw interrupt queue length. # IP sw interrupt queue len, default 50; # check queue drops stats in net.inet.ip.intr_queue_drops net.inet.ip.intr_queue_maxlen=1000 Hope this helps Aniruddha