Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 3 Oct 2012 18:03:42 -0400
From:      Ryan Stone <rysto32@gmail.com>
To:        d@delphij.net
Cc:        Garrett Cooper <yanegomi@gmail.com>, freebsd@chrysalisnet.org, Adrian Chadd <adrian@freebsd.org>, freebsd-current@freebsd.org
Subject:   Re: sysctl kern.ipc.somaxconn limit 65535 why?
Message-ID:  <CAFMmRNxrBTV_wbU=KS%2BrZzPn7xbkcShjSv4tu5-EDZJSc7E2dA@mail.gmail.com>
In-Reply-To: <506CA848.5040604@delphij.net>
References:  <03e101cda197$326dc240$974946c0$@org> <CAJ-Vmo=CtC1SpsedP3nHJsrApTLzktGrjopeV0vXShr0FOUsmA@mail.gmail.com> <CAGH67wT-v6B6NT1ETLX1V-w4OJDosst9xQ7UPE2d%2BVvFgosdPA@mail.gmail.com> <506CA848.5040604@delphij.net>

next in thread | previous in thread | raw e-mail | index | archive | help
>> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNxrBTV_wbU=KS%2BrZzPn7xbkcShjSv4tu5-EDZJSc7E2dA>