[erlang-questions] listen() backlog limited to 16 bits?
Tue Apr 28 07:54:34 CEST 2009
On Monday, April 27, Matthew Dempsky wrote:
> My only point is that (AFAIK) the listen backlog doesn't directly
> affect the number of requests per second or the number of concurrent
> connections you can handle. It's just the number of TCP connections
> that have completed the SYN/ACK handshake and not yet been accepted by
> user space, and I just wouldn't expect this number to get into the
> hundreds of thousands unless the system is heavily overloaded, and
> then it probably can't do anything useful with such a huge backlog
I had similar thoughts. I can imagine a short backlog limit, e.g. 5,
limiting throughput, but I can only think of contrived situations
where there'd be a difference between millions and thousands.
The OS backlog limit has increased in linux over the
years. Originally, it was five connections (BSDism?). Later
(2.0/2.2/2.4?), it increased to 128. In current Linux versions it's
configurable without an apparent upper limit; the default is 128.
Someone thought it was worth the effort to remove the limit. I googled
a bit and couldn't find the reasoning behind that. Maybe it was a
"remove all arbitrary limits" mission.
* I've tried writing higher values to somaxconn and reading them
back again. It gets a bit weird for some values:
contorpis:/proc/sys/net/core# echo "2147483648" > somaxconn
contorpis:/proc/sys/net/core# cat somaxconn
I also tried a C program with various backlog arguments. It feels
like something strange is going on, e.g. with a call to listen(s,
1) and then sleep() forever, I can still connect several sockets,
though it takes about a second per connection after the first
few. I wasn't sufficiently interested to figure out why, but if
someone knows, it'd be interesting to hear.
More information about the erlang-questions