From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:51:39 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 591DB106564A for ; Wed, 4 Jan 2012 20:51:39 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF158FC12 for ; Wed, 4 Jan 2012 20:51:39 +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 asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LXA001EUKLQ8H40@asmtp026.mac.com> for freebsd-current@freebsd.org; Wed, 04 Jan 2012 12:51:26 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110,1.0.211,0.0.0000 definitions=2012-01-04_07: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-1201040220 From: Chuck Swiger In-reply-to: Date: Wed, 04 Jan 2012 12:51:25 -0800 Message-id: <52A4B11E-592E-458D-BA0F-9B5A349F4B73@mac.com> References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@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 20:51:39 -0000 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. Regards, -- -Chuck