Why set keepalive_timeout to a short period when Nginx is great at handling them?

Aahan Krish krish at aahan.me
Sat Jun 18 15:29:30 UTC 2016


Hi B.R.,

You raised a good point.

So you are referring to the 4-tuple (source_IP, source_port,
server_IP, server_port) socket limitation, correct? I just came to
know about this and it's interesting. Please tell me if this
understanding of mine is correct:

    So a server identifies a user's connection based on a combination
of: user's internet connection's IP + port the user's client is
connecting from (e.g. Chrome on 8118, IE on 8080, etc.) + server IP +
server_port (80 for HTTP / 443 for HTTPS).

    And the limitation is that a maximum of ~ 65536 clients all on
same port (say all are using Chrome and therefore connecting from
8118) can connect simultaneously to a web server that is connected to
the internet via 1 public IP address and port 80 (let's say HTTP
only), IFF the resources of the server permit.

    And that means I can double the no. of connections (2x 65536 per
second) my server can handle, if it has enough resources in the first
place (i.e. sufficient RAM, CPU, I/O capacity or whatever is relevant)
by simply adding another public IP address to my server and making
sure that the traffic is load-balanced between the two public IPs of
the server.

    Am I correct?

    (If my understanding is correct, this comment was helpful:
http://stackoverflow.com/q/34079965#comment55913149_34079965)

Check out the post I recently made to this list answering my own
question about `keepalive_timeout`:
<http://mailman.nginx.org/pipermail/nginx/2016-June/051026.html>

If you follow ((5)) in the post, you'll note that `keepalive_timeout`
set to anything over 300s or 5m is probably pointless as most browsers
drop the keep-alive connection in under 2 min, and 5 minutes max. This
is just an FYI as I'd like to hear what you think.

Lastly, your suggestion on utilizing `keepalive_requests` to recycle
keep-alive connections is smart. Noted.

I think I learnt a lot today. =)



More information about the nginx mailing list