Re: sysctl kern.ipc.somaxconn limit 65535 why?

From: Xin Li <delphij_at_delphij.net>
Date: Wed, 04 Jan 2012 18:06:17 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/04/12 17:49, Chuck Swiger wrote:
> Hi, Xin--
> 
> On Jan 4, 2012, at 5:32 PM, Xin Li wrote:
>> I am personally quite convinced that FreeBSD should make such
>> change though -- having more than 64K of outstanding and
>> unhandled connections does not sound a great idea (i.e. it's not
>> a connection limit after all, but the pending handle connection.
>> If my math were right, 64K connections would require about 1Gbps
>> bandwidth in and out if they happen in the same second.)  But I
>> agree this would be a good stress test, which might expose some
>> bugs we don't know today.
> 
> I think I agree with the change from a correctness standpoint--
> listen(2) accepts an int backlog argument.
> 
> I'm not convinced that there are many scenarios where needing to
> exceed a listen queue backlog of 64K would be beneficial to a
> real-world system, and I am sure there are many scenarios where it
> would be counterproductive, but folks can adjust kern.ipc.somaxconn
> as they see fit and perhaps Dan or others would gain some value
> from it.

Ah sorry that should read something like "I'm not quite convinced" and
as you see I were explaining why in detail but apparently I missed to
check the spellings...

Cheers,
- -- 
Xin LI <delphij_at_delphij.net>	https://www.delphij.net/
FreeBSD - The Power to Serve!		Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8FBZkACgkQOfuToMruuMDQqQCfWPenaWKpC41i8CXJeuFPlAzg
y/cAnR2zTBCa1qG3/0G/nP/vDbQ5Z3vp
=lGcl
-----END PGP SIGNATURE-----
Received on Thu Jan 05 2012 - 01:06:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:22 UTC