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

From: Dan The Man <dan_at_sunsaturn.com>
Date: Wed, 4 Jan 2012 15:15:11 -0600 (CST)
On Wed, 4 Jan 2012, Dan The Man wrote:

>
> On Wed, 4 Jan 2012, Chuck Swiger wrote:
>
>> On Jan 4, 2012, at 12:44 PM, Dan The Man wrote:
>>>> 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.
>> 
>> Sure, agreed.
>> 
>>> 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:~#
>> 
>> However, I'm not convinced that it is useful to do this.  At some point, 
>> you are better off timing out and retrying via exponential backoff than you 
>> are queuing hundreds of thousands of connections in the hopes that they 
>> will eventually be serviced by something sometime considerably later.
>> 
>
> I agree completely, in practical application this makes sense, but why should 
> the OS dictate not being able to temporarily set that setting higher in order 
> to fully benchmark the application at 100k+ in the listen queue if the 
> developer so chooses? I think that alone should be a good reason, to make 
> freebsd developer friendly.


Anyways its not a big deal I can live with a 60k or so benchmark, I just 
really wanted to see how freebsd's kqueue would perform processing that 
many connections right out of the listen queue.



Dan.

--
Dan The Man
CTO/ Senior System Administrator
Websites, Domains and Everything else
http://www.SunSaturn.com
Email: Dan_at_SunSaturn.com
Received on Wed Jan 04 2012 - 20:15:11 UTC

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