From: Hagen Paul Pfeifer <hagen@jauu.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, eric.dumazet@gmail.com
Subject: Re: [PATCH] socket: increase default maximum listen queue length
Date: Sun, 20 Mar 2011 12:59:50 +0100 [thread overview]
Message-ID: <20110320115950.GB3038@nuttenaction> (raw)
In-Reply-To: <20110319.214100.183043711.davem@davemloft.net>
* David Miller | 2011-03-19 21:41:00 [-0700]:
>What in the world is a server running on multi-GHZ cpus doing such
>that it cannot accept() fast enough to keep up with a 100 connections
>per second?
>
>We were handling that just fine 10+ years ago.
>
>The math simply doesn't add up.
Davem, what the hell - you don't get it! ;-) No Davem, the problem is not the
accept() performance rather it is the time since SYN/ACK is arrived and
request_sock are created: RTT time to the client (including client SYN/ACK
processing) and finally the accept() processing time. During _this_ duration
the backlog is of relevance. For connection with a high RTT the backlog can be
quite high - local accept() processing delay does not really matter.
The actual behavior is not really fine. max_syn_backlog and somaxconn are
somewhat[TM] unsynchronized. max_syn_backlog considers the system memory
characteristic where somaxconn is just a dump show stopper. My patch is a
compromise it increase the value to 256 because it showed up that 256 seems
reasonable for many setups. Many system administrators will not notice the
problem, server authors may know about this limitation (and adjust the listen
argument)- so why should we make the life of the administrators a little bit
more easy by adjusting the default? Low memory systems does not suffer, the
limit is still reasonable small. The memory footprint for a server with 4
listening sockets is just insignificant. But connection failure due to backlog
limits will magically go away.
The math is a function from incoming connections / time, the RTT and
processing delay of client and server side..
Have a nice Sunday, Hagen
next prev parent reply other threads:[~2011-03-20 11:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-20 1:50 [PATCH] socket: increase default maximum listen queue length Hagen Paul Pfeifer
2011-03-20 4:41 ` David Miller
2011-03-20 11:59 ` Hagen Paul Pfeifer [this message]
2011-03-20 8:30 ` Eric Dumazet
2011-03-20 9:04 ` Rémi Denis-Courmont
2011-03-20 9:36 ` Eric Dumazet
2011-03-20 11:39 ` Hagen Paul Pfeifer
2011-03-20 11:55 ` Eric Dumazet
2011-03-20 12:14 ` Hagen Paul Pfeifer
2011-03-20 23:04 ` [PATCH 1/2] " Hagen Paul Pfeifer
2011-03-20 23:04 ` [PATCH 2/2] socket: add minimum listen queue length sysctl Hagen Paul Pfeifer
2011-03-21 7:36 ` Eric Dumazet
2011-03-20 23:09 ` [PATCH 1/2] socket: increase default maximum listen queue length David Miller
2011-03-20 23:52 ` Hagen Paul Pfeifer
2011-03-21 0:18 ` David Miller
2011-03-20 23:57 ` Hagen Paul Pfeifer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110320115950.GB3038@nuttenaction \
--to=hagen@jauu.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).