What exactly does keepalive_timeout work?

[Richard Stanway]

You generally want as long a keepalive timeout as you're able to tolerate.
Closing the connection after 5 seconds for example means a full new TCP and
TLS handshake has to occur if the user clicks a link after 5 seconds,
resulting in a minimum of two RTTs before content, causing a slow loading
experience. If you have long pages that could take minutes to read before a
user loads another page, then for best performance you want keepalive at 5+
minutes for example. Keep in mind this is an upper limit - the browser is
free to choose when to close the connection on the client too.

The reason you will sometimes see recommendations to have a low keepalive
timeout is to improve performance of legacy forking web servers where each
client connection consumed an entire process and thus lots of memory.
Having lots of idle clients on such servers caused heavy memory usage and
was not recommended. Of course nginx has no such problem since it's event
based.

On Fri, Jun 17, 2016 at 10:49 AM, Aahan Krish <krish at aahan.me> wrote:

> Hi,
>
> I'd like to understand how `keepalive_timeout` works. The description
> in the documentation isn't very clear and I couldn't get an answer to
> my satisfaction on #nginx IRC.
>
> People seem to have their own understanding of how `keepalive_timeout`
> works and they are very different.
>
> 1. For e.g. <
> https://github.com/roots/trellis/blob/master/roles/nginx/templates/nginx.conf.j2
> >
> describes the directive like this:
>
>     # How long to allow each connection to stay idle; longer values are
> better
>     # for each individual client, particularly for SSL, but means that
> worker
>     # connections are tied up longer. (Default: 65)
>
> So according to the statement `keepalive_timeout` is to be used to
> tell how long a server needs to keep the connection alive AFTER
> serving all the requests.
>
> And this commenter seems to agree:
> <http://serverfault.com/q/331762#comment665957_331764>
>
> > [It's] only a timeout during which server waits for another request
> > up to [the limit set by] `keepalive_requests`. So it is not important
> > how much time it takes for the full page to load [...] BTW the max.
> > time connection is kept open is almost:
> >
> >     keepalive_timeout * keepalive_requests
>
> 2. Then there are people understand the function of
> `keepalive_timeout` like so: http://stackoverflow.com/a/10202959
>
> > HTTP Keep-Alive is a feature of HTTP protocol. The web-server,
> > implementing Keep-Alive Feature, has to check the connection/socket
> > periodically (for incoming HTTP request) for the time span since it
> > sent the last HTTP response (in case there was corresponding HTTP
> > Request). If no HTTP request is received by the time of the configured
> > keep-alive time (seconds) the web server closes the connection.
>
> Similar opinion from another: http://serverfault.com/a/331764
>
> > There isn't a good one-size-fits-all answer; if most client browsers
> > are able to load all the resources on a page in 5 seconds then 5
> > seconds is just fine [...]
>
> So according to these people the directive is to be calculated in such
> a way that in that given time (on an average) a web page on your site
> and its contents (HTML, CSS, JS, images) are completely loaded on most
> clients.
>
> THE QUESTION: So which one is it? (1) or (2)? Who's right?
>
> _______________________________________________
> 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/20160617/939fc94f/attachment.html>