From owner-freebsd-current@FreeBSD.ORG Wed Jan 4 20:44:02 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 2F7C71065670 for ; Wed, 4 Jan 2012 20:44:02 +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 076218FC15 for ; Wed, 4 Jan 2012 20:44:01 +0000 (UTC) Received: by sunsaturn.com (Postfix, from userid 1001) id 74DCA119C79; Wed, 4 Jan 2012 14:44:01 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sunsaturn.com; s=gamma; t=1325709841; bh=fPbsAAQzN3B13zrwY/lDdjJJgTxqTVfapJhloGrqokw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=I+gF6L95UsAazGWz8T6UyK02ttBK8wUbEFtbIM55d+hqg8v4S0p/5sWau+vUejFmd DA6tj1uUdob7IyBQme9jAkWav5yt8zoQrdd0WuLdMK3mlqHpFZgK7oARarc+Wo+RnN do7eqmhSXFEceOhFM5yyVqG+HOoitWnhU/Lf3/hc= Received: from localhost (localhost [127.0.0.1]) by sunsaturn.com (Postfix) with ESMTP id 6F87D119C6E; Wed, 4 Jan 2012 14:44:01 -0600 (CST) Date: Wed, 4 Jan 2012 14:44:01 -0600 (CST) From: Dan The Man To: Chuck Swiger In-Reply-To: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@mac.com> Message-ID: References: <0A9B7C39-DFA9-4C65-BE39-CC72E18DAB87@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 20:44:02 -0000 On Wed, 4 Jan 2012, Chuck Swiger wrote: > On Jan 4, 2012, at 12:22 PM, Dan The Man wrote: >> Trying to stress test a framework here that tosses 100k of connections into a listen queue before doing anything, I realize I'll have to use multiple local IPs get get around port limitations, but why is this backlog using a limit? > > 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. 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:~# Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: Dan@SunSaturn.com