From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 21:42:48 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 D6C87106566B for ; Wed, 4 Jan 2012 21:42:48 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id B9DDF8FC15 for ; Wed, 4 Jan 2012 21:42:48 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp021.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA00ENUMZBVS20@asmtp021.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 21:42:48 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_08:2012-01-04, 2012-01-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201040240 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 13:42:47 -0800 Message-id: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> To: Dan The Man X-Mailer: Apple Mail (2.1084) 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:42:48 -0000 On Jan 4, 2012, at 1:03 PM, Dan The Man wrote: >> 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. The job of the OS is to manage resources on behalf of the users and processes using the system. Some developers feel that VM means that the system should always claim have more memory available, but always saying "yes" isn't "managing resources". I'd rather have the OS return a null pointer and set ENOMEM when someone tries to malloc() more memory than the system (including swap, VM overcommit, etc) has, and I expect developers to code well enough to handle malloc() failures. Setting the listen queue to an arbitrarily high value isn't useful, and developers would be better advised to pay attention to best practices in the face of a massive connection backlog. Regards, -- -Chuck