hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Potapov <potapo...@gmail.com>
Subject Re: HttpCore NIO performance improvements
Date Mon, 25 Feb 2013 05:23:54 GMT
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.

-- 
Best regards,
Dmitry

On Fri, Feb 22, 2013 at 12:31 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Thu, 2013-02-21 at 22:21 +0300, Dmitry Potapov wrote:
>> I just want to say that when I'm setting TCP_NODELAY I expect that every
>> portion of data is being transmitted right after I called
>> ContentEncoder.write() (even without waiting for ACK for previous TCP
>> packet)
>> I've looked through the code in trunk, and looks like this expectation
>> will fail after this change.
>>
>
> Dmitry
>
> I am not entirely sure I understand what your expectation is based upon
> but I am not a TCP/IP specialist. At any rate you can force HttpCore to
> always write things out directly to the underlying channel by setting
> the fragment hint parameter to zero.
>
> Hope this helps
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Mime
View raw message