In response to part II of what is proving to be our ongoing blog post series on TIME_WAIT, our reader Ryan wrote:
I've been looking at a few IIS servers that are currently exhibiting the TIME_WAIT behavior that you describe. In addition to the 2MSL timeout, HTTP keep-alives and the corresponding connection timeout seem to have a bearing on the duration of TIME_WAIT. The particular servers I'm looking at have a very long connection timeout setting, so I am trying to minimize the number of TIME_WAIT connections. That said, I'm having difficulty replicating TIME_WAIT connections. The only way I've been able to make it happen thus far is to disable keep-alives in IIS. Can you elaborate on the role of HTTP keep-alives in the TIME_WAIT scenario?
A couple of things here: First, it certainly makes sense that disabling keep-alives altogether would cause the TIME_WAITs to spike noticably. After all, persistent connections were explicitly intended (among other things) to minimize the proportion of sockets in the TIME_WAIT state. Fewer connections shutting down for a given load, means fewer sockets going into TIME_WAIT.
Second, it would be interesting to know what kind of variation Ryan is expecting to see in the TIME_WAIT state, based on changes in the connection timeout. Since the longer-lived the connection, the more likely it is to pick up a new request and therefore avoid going into the full duplex close, you would expect to see fewer TIME_WAITs, at any given time, on an equally-loaded server with longer connection timeouts. But that would mean that servers having longer connection timeouts would be precisely the ones with the least need for minimizing the duration of the TIME_WAIT state (i.e., that accumulation of TIME_WAITs would be least on those servers), while Ryan's question seems to imply that he is seeing the reverse of this.
But perhaps we're missing something here. If so, Ryan -- or anyone else out there who is on the same wavelength -- please enlighten us.
In the meantime, a very happy holiday to all from the whole crew at Port80!