Date: Mon, 12 Feb 2001 10:53:30 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Peter Wemm <peter@netplex.com.au> Cc: net@FreeBSD.ORG, jlemon@FreeBSD.ORG Subject: Re: somaxconn and foot removal Message-ID: <20010212105330.C3274@fw.wintelcom.net> In-Reply-To: <200102111330.f1BDUGU36650@mobile.wemm.org>; from peter@netplex.com.au on Sun, Feb 11, 2001 at 05:30:16AM -0800 References: <20010211015949.K3274@fw.wintelcom.net> <200102111330.f1BDUGU36650@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Peter Wemm <peter@netplex.com.au> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010212105330.C3274>