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

[B.R.]

There is no downside on the server application I suppose, especially since,
as you recalled, nginx got no trouble for it.

One big problem is, there might be socket exhaustion on the TCP stack of
your front-end machine(s). Remember a socket is defined by a triple
<protocol, address, port> and the number of available ports is 65535 (layer
4) for every IP (layer 3) double <protocol, address>.
The baseline is, for TCP connections underlying your HTTP communication,
you have 65535 port for each IP version your server handles.

Now, you have to consider the relation between new clients (thus new
connections) and the existing/open ones.
If you have very low traffic, you could set an almost infinite timeout on
your keepalive capability, that would greatly help people who never sever
connection to your website because they are so addicted to it (and never
close the tab of their browser to it).
On the contrary, if you are very intensively seing new clients, with the
same parameters, you would quickly exhaust your available sockets and be
unable to accept client connections.

On the opposite scenario where you are setting a timeout on keepalive which
is too low, you would hurt you server performance by using CPU to manage
overhead connections for a single client, thus wasting resources and
inducing latency, which are issues keepalive helps to address.

Given the 65535 ports limitation is not going to change, at least in a
recent future (hardcoded on 16 bits in nowadays protocols), you have
essentially 2 parameters to consider:
- How often you get new clients
- What is the mean time users spend connected to your server(s)

Those should help you define the most efficient keepalive timeout. nginx
sets the default time for it at 75 seconds
<http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout>.

On a side note, there are also browser trouble with it, see
keepalive_disable
<http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable>.

And finally, nginx provides the ability to recycle connections based on a
number of requests made (default 100).
I guess that is a way of mitigating clients with different behaviors: a
client having made 100 requests is probably considered to hav had its share
of time on the server, and it is time to put it back in the pool to give
others access in case of congestion.
On the other hand, a client taking its time to browse your website (and
thus not reaching the requests limit) should be given the whole timeout
time allocated on the server.
I see no other reason than justice/balancing here, no technical one which
is other than th already addressed one: giving each client enough time to
browse the website with minimal disconnection, while avoid resources
unfairly taken away from other people.

I might be misled, in which case I ocunt on people to correct me.
I suggest you also read:
- https://www.nginx.com/blog/tuning-nginx/ ('Keepalive Connections' part)
- and more importantly
https://www.nginx.com/blog/http-keepalives-and-web-performance/
---
*B. R.*

On Sat, Jun 18, 2016 at 1:26 PM, Aahan Krish <krish at aahan.me> wrote:

> I read something interesting today:
> <
> https://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/
> >
>
> "Keep alive is a HTTP feature which allows user agents to keep the
> connection to your server open for a number of requests or until the
> specified time out is reached. This won’t actually change the
> performance of our nginx server very much as it handles idle
> connections very well. The author of nginx claims that 10,000 idle
> connections will use only 2.5 MB of memory, and from what I’ve seen
> this seems to be correct.""
>
> So why is it that people on the web (and in IRC) still recommend
> setting `keepalive_timeout` to a short period (< 30 seconds) when
> Nginx can handle idle keep-alive connections like a champ (using very
> little resources) while serving active ones? Is that bad advise?
>
> I get this advise so often that I believe there must be something that
> I am missing. What's it?
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160618/6099e625/attachment.html>