There is no downside on the server application I suppose, especially
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
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
your keepalive capability, that would greatly help people who never
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
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
On a side note, there are also browser trouble with it, see
And finally, nginx provides the ability to recycle connections based on
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
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
is other than th already addressed one: giving each client enough time
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: