On Thu, Mar 16, 2017 at 7:31 AM, Lutz Vieweg <l...@5t9.de> wrote:
>
> On 03/15/2017 11:55 PM, Willy Tarreau wrote:
>>
>> At least I can say I've seen many people enable it without understanding its
>> impact, confusing it
>> with tcp_tw_reuse, and copy-pasting it from random blogs and complaining
>> about issues in
>> production.
>
>
> I currently wonder: What it the correct advise to an operator who needs
> to run one server instance that is meant to accept thousands of new,
> short-lived TCP connections per minute?
Note that for this to be a problem there would have to be thousands of
new, short-lived TCP connections per minute from a single source IP
address to a single destination IP address. Normal client software
should not be doing this. AFAIK this is pretty rare, unless someone is
running a load test or has an overly-aggressive monitoring system. NAT
boxes or proxies with that kind of traffic should be running with
multiple public source IPs.
But if/when the problem occurs, then the feasible solutions I'm aware
of, in approximate descending order of preference, are:
(1) use longer connections from the client side (browsers and RPC libraries are
usually pretty good about keeping connections open for a long time, so this
is usually sufficient)
(2) have the client do the close(), so the client is the side to carry the
TIME_WAIT state
(3) have the server use SO_LINGER with a timeout of 0, so that
the connection is closed with a RST and the server carries no
TIME_WAIT state
neal
