From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 22:03:50 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 E970D106566C; Wed, 3 Oct 2012 22:03:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7E0CA8FC14; Wed, 3 Oct 2012 22:03:49 +0000 (UTC) Received: by vbmv11 with SMTP id v11so10980158vbm.13 for ; Wed, 03 Oct 2012 15:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PAWzIXwSoKrlWxZXP2D9CgVl7aG/8g9E6WJOTQImblU=; b=FCWh4IjYUfUgJ0VpPhl4Vicb6eZbGhMgDbpmCvp+KTCOYo5xSPsc2ju1PlEZ0MDqj7 tewuH+1XWOqBvlZt2ZJ9mlG3TTWoqOvrhQDTZGDAalzwZCuoTBzfTQo93yazk0lULZ+T 5K69xHHFyEkWdupFHHZQJkhGxg/3rEBvdLoDLfdU1FN0AIsz2MC2UCr8BKCJsliMvUgF 3P4zvn/q50MiDAzAsu0TwRtJ690KbGbLtLSISPuPAXktNMZ1qIuXq1O6i5+EGlPLIybj 2Hk10foA8mpaK2nRpva8Xdq0VgQqj+uuieVCLlhTNXc4XG5mZU1wTulCZRwQjoTtYG3G RUZg== MIME-Version: 1.0 Received: by 10.220.154.6 with SMTP id m6mr1890354vcw.51.1349301822788; Wed, 03 Oct 2012 15:03:42 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Wed, 3 Oct 2012 15:03:42 -0700 (PDT) In-Reply-To: <506CA848.5040604@delphij.net> References: <03e101cda197$326dc240$974946c0$@org> <506CA848.5040604@delphij.net> Date: Wed, 3 Oct 2012 18:03:42 -0400 Message-ID: From: Ryan Stone To: d@delphij.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Garrett Cooper , freebsd@chrysalisnet.org, Adrian Chadd , 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, 03 Oct 2012 22:03:50 -0000 >> Or the TTL of TCP connections might be too high for the volume of >> connections received. Someone else on net@ reported that changing >> this value to more aggressively reap sockets improved performance >> greatly (at the cost that more connections potentially needing to >> be reestablished and/or getting dropped on the floor if things go >> too high volume). > > That's a different topic I think. On busy web servers it's fairly > typical to have a lot of TCP sockets staying in TIME_WAIT state for > extended time and the usual tuning would be to set MSL to about 2 > seconds at the expense of sacrificing slow clients who can't make > 3-way handshake in time (*), etc. The TTL of IP packet have nothing > to do with this though, and our default (64) is saner than many other > operating systems. Presumably RTT was meant here instead of TTL.