hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HttpCore NIO performance improvements
Date Mon, 25 Feb 2013 10:59:35 GMT
On Mon, 2013-02-25 at 08:23 +0300, Dmitry Potapov wrote:
> Ok, let me explain. When TCP_NODELAY is set to false, the Nagle's
> algorithm (rfc896) is enabled for socket. What this algorithm does?
> For each portion of data written to socket no data will be transmitted
> over TCP until at least one of two conditions is met:
> 1. ACK for the previous portion of data is received from the remote
> host (i.e. no data is sent until remote host confirm that previous
> portion of data is received)
> 2. Socket buffer is full (i.e. the overhead of TCP headers is minimal,
> no more data can be added to the current buffer without creating new
> packet with its own TCP headers)
> Second statement is what your modification does.
> When TCP_NODELAY is set to true, the Nagle's algorithm is disabled and
> user expects that all data written to socket is sent immediately. That
> is: Nagle's algorithm is about efficiency, TCP_NODELAY == true is
> about latency.
> It is no wonder that you gained speed boost with TCP_NODELAY set to
> true, because in fact you partially repeated TCP_NODELAY == false
> behaviour, but users who intentionally set TCP_NODELAY to true will
> get increased latency and it will be hard to find the root cause
> without reading this thread or the source code.
> My opinion is that such kind of data buffering must be enabled only
> whet TCP_DELAY is set to false, as it will reduce the number of
> syscalls. For TCP_DELAY set to true, no buffering is acceptable.


The primary purpose of the Nagle's algorithm is _congestion_ control and
flooding prevention. This is in part achieved by avoiding excessive
packet fragmentation mainly when transmitting terminal interactions
(that often consist of a single keystroke). But efficiency is not the
main point of RFC 896. More importantly, though, RFC imposes _no_
restriction of any nature on data buffering in protocol layers on top of


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message