From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 22:27:21 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 53E9C1065670; Wed, 3 Oct 2012 22:27:21 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7838FC12; Wed, 3 Oct 2012 22:27:20 +0000 (UTC) Received: by ieak10 with SMTP id k10so18438684iea.13 for ; Wed, 03 Oct 2012 15:27:20 -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=w0X+gp4FAQVUoQwjPn0BQAU+z5Ked1yBnKOS3Egs0nw=; b=s8zLFimjPDAt/3n3WzAgj0ZotdfofuDS4mMChqVb2DyWjBNChRnqML13FmhctMVnV+ B1m9jv+bEhDE4ntNnKfU97s5qlSQnwG72GzdjX5/N33plMPdHSLF1prFzoMKw8uO2iqA Z8o1CBJ/xiYUrAhI9dcyN1Gv755yvZOjnrT2B4bxUFZgf9tUu7ih5vn5faCdCIKTVKvu up9iPNdSjQuOQkrbUc4ySw/A7UFUhh9KyLFdJ21qYJdmQv5Fw/N3f64hjoQ2UqpBYW5p hioDSN3f2mrtRFz+Ia2XY7FGDyGyoMAFVGDIv/Fq5VsuzmaqrinvB5SEyMVzGeTXAK2C OBQA== MIME-Version: 1.0 Received: by 10.50.197.231 with SMTP id ix7mr3417781igc.54.1349303240239; Wed, 03 Oct 2012 15:27:20 -0700 (PDT) Received: by 10.64.51.39 with HTTP; Wed, 3 Oct 2012 15:27:20 -0700 (PDT) In-Reply-To: References: <03e101cda197$326dc240$974946c0$@org> <506CA848.5040604@delphij.net> Date: Wed, 3 Oct 2012 15:27:20 -0700 Message-ID: From: Garrett Cooper To: Ryan Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd@chrysalisnet.org, Adrian Chadd , freebsd-current@freebsd.org, d@delphij.net 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:27:21 -0000 On Wed, Oct 3, 2012 at 3:03 PM, Ryan Stone wrote: >>> 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. Yes, I screwed up my nomenclature and TIME_WAIT was what I was trying to note. Thanks! -Garrett