Hacker News Reader

Comment by joosters | Hacker News Reader

If your servers are handling HTTP traffic, another big win is to make sure HTTP keep-alives are enabled on the servers. This will cause connections to be reused and so fewer connections will be closed.

View on HN

More importantly, the TIME_WAIT state only happens for the socket that initiated the close (active close). In the case of a HTTP keep-alive, the active close is usually done by the client instead of the server (avoiding a TIME_WAIT on the server side).

A general rule when designing a network protocol : do your best to make the client-side closes the connection when possible.

Very true.

Note that the web page discusses load balancers in a few places. If you have such a setup, the LB is effectively acting as a client and so the TIME_WAITs will still pile up on one of your machines.

If the load balancer can re-use the HTTP connections from LB<->web server with keepalives, then it will reduce them.

Unless of course you have a high bounce rate (intended or otherwise) never use HTTP keep-alive.

Can you provide some background on when and why you believe this is good advice? Otherwise this is exactly the kind of technical folklore the original post was complaining about – it's a broad assertion with no supporting theory to help people understand whether it's applicable to their situation.

I think they're trying to say that if someone is likely to make just the one connection to your site, and then never fetch further pages, then you don't want to turn keep-alive on. There would be no point maintaining the connection if the client isn't likely to use it.

Imagine you run a site that provided a common javascript library. People are encouraged to add a link to fetch the .js file from their 3rd party webpages. So most clients contacting your server will be there to fetch one file only. Even if the user continues to browse the 3rd party website, they won't make further requests to your server. One connection, one request. Here, keepalives would be a bad idea.

I'm pretty sure the explanation is something like that but I felt the sloppy wording and completely lack of any explanation was exactly the kind of thing we need less of in tech advice, particularly when describing an extreme edge-case.

The original wording was poor enough that it's ambiguous whether the claim is “enable keepalive unless you have a high bounce rate” or “enable keepalive if you have a high bounce rate”.

I meant do NOT use keep-alive if you have a high bounce rate.

High traffic and high bounce rate, will leave a lot of TIME_WAIT hanging around for precious seconds and soon enough your server won't be able to accept new connections.

Obviously this applies if you have both: high traffic and high bounce rate. Any high traffic service over TCP where a client connects to the server for a very brief moment and doesn't come back until hours or days later, or never.

These are exactly the missing details, modulo the qualifier that "high traffic" generally means at least tens of thousands of persistent connections on a modern web server.

I think you mean the opposite advice of the natural reading of your text.

I read your advice as "Only use HTTP keep-alive if you have a high bounce rate", when I presume you mean the opposite.

  1. Unless P, then Q.
  2. P is "have a high bounce rate"
  3. Q is "do not use keep alives"

I think you meant:

  1. If P, then Q.
  2. P and Q same as above.

Yes, I meant do NOT use keep-alive if you have a high bounce rate.

Can't edit the above post, but what I meant was: do NOT use keep-alive if you have a high bounce rate.

Apologies for the poor wording.

Reply on news.ycombinator.com