From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:15:11 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B80FB1065672 for ; Wed, 4 Jan 2012 21:15:11 +0000 (UTC) (envelope-from dan@sunsaturn.com) Received: from sunsaturn.com (mail1.sunsaturn.com [IPv6:2001:49f0:4004::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB798FC18 for ; Wed, 4 Jan 2012 21:15:11 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 37B29119C6E; Wed, 4 Jan 2012 15:15:11 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325711711; bh=DfSR2yN8pQuu+xSQQiOh4SxVjLuGMO/TyUE6tJVKgqI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=bi09YccRPjbjw2taEIQt8TksUZdC8bSOEXd9s8rMueLOaWoZPuY3TOKwo3m09zn2N VN9NBfrjofgGXrcVs9ZkT12LRF+ZIyWi7lUXXTvFuZfbj6ZjfLhc2DRs0PzYPWyYGD uoYzAyPU1lF0npRgZ2RTYEKBI78OuJpgEKO0VpbQ= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 369CF119C56; Wed, 4 Jan 2012 15:15:11 -0600 (CST) Date: Wed, 4 Jan 2012 15:15:11 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:15:11 -0000 On Wed, 4 Jan 2012, Dan The Man wrote: > > On Wed, 4 Jan 2012, Chuck Swiger wrote: > >> On Jan 4, 2012, at 12:44 PM, Dan The Man wrote: >>>> Even a backlog of a 1000 is large compared to the default listen queue >>>> size of around 50 or 128. And if you can drain 1000 connections per >>>> second, a 65K backlog is big enough that plenty of clients (I'm thinking >>>> web-browsers here in particular) will have given up and maybe retried >>>> rather than waiting for 60+ seconds just to exchange data. >>> >>> For web browsers makes sense, but if your coding your own server >>> application its only a matter of increasing the read and write timeouts >>> to fill queue that high and still process them. >> >> Sure, agreed. >> >>> Of course wouldn't need anything that high, but for benchmarking how much >>> can toss in that listen queue then write something to socket on each one >>> after connection established to see how fast application can finish them >>> all, I think its relevant. >>> >>> This linux box I have no issues: >>> cappy:~# /sbin/sysctl -w net.core.somaxconn=200000 >>> net.core.somaxconn = 200000 >>> cappy:~# sysctl -w net.ipv4.tcp_max_syn_backlog=20000 >>> net.ipv4.tcp_max_syn_backlog = 200000 >>> cappy:~# >> >> However, I'm not convinced that it is useful to do this. At some point, >> you are better off timing out and retrying via exponential backoff than you >> are queuing hundreds of thousands of connections in the hopes that they >> will eventually be serviced by something sometime considerably later. >> > > I agree completely, in practical application this makes sense, but why should > the OS dictate not being able to temporarily set that setting higher in order > to fully benchmark the application at 100k+ in the listen queue if the > developer so chooses? I think that alone should be a good reason, to make > freebsd developer friendly. Anyways its not a big deal I can live with a 60k or so benchmark, I just really wanted to see how freebsd's kqueue would perform processing that many connections right out of the listen queue. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com