From owner-freebsd-net Mon Feb 12 10:53:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 026F637B491; Mon, 12 Feb 2001 10:53:36 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f1CIrVn03733; Mon, 12 Feb 2001 10:53:31 -0800 (PST) Date: Mon, 12 Feb 2001 10:53:30 -0800 From: Alfred Perlstein To: Peter Wemm Cc: net@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: somaxconn and foot removal Message-ID: <20010212105330.C3274@fw.wintelcom.net> References: <20010211015949.K3274@fw.wintelcom.net> <200102111330.f1BDUGU36650@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102111330.f1BDUGU36650@mobile.wemm.org>; from peter@netplex.com.au on Sun, Feb 11, 2001 at 05:30:16AM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Peter Wemm [010211 05:30] wrote: > > For what it's worth, we found (at Yahoo) that excessively large listen > queues tend to cause more problems than they solve. The circumstances are > probably different, but we found that on one particular application, a > queue of 10 was better than the queue of 1024 that they had been using. > This particular application is probably quite different to yours, but we > found that it was generally bad to accept more than about a second or two's > worth of connections. ie: this particular group of systems were processing > 7-8 connections per second, so a queue depth of 1024 was about 140 seconds. > Most of them would time out when they waited that long (30 or 60 second > protocol timeout) so when the machine was overloaded and backing up, it was > being made worse by accepting all these connections, doing processing to get > them in the listen queue, then timing out. What we ended up with was a LOT > of races where sockets would get to the head of the queue right as the > remote was in the process of initiating a timeout, so we got large numbers > of 'connection reset by peer' type problems being reported by accept and > getsockname()/getpeername() etc. It was also bad because the userland app > then wasted time processing a dying connection, thus contributing further > to the overload. > > Anyway, just be careful, ok? larger listen queues are not a magic solution > for all problems. At 100 connections per second, the current limit is about > 327 seconds worth of delay. at 500 per second, it is 65 seconds delay. I'm a bit past 500 connections per second. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message