Ok I have conducted some experimentations :

1) The HeapBuffer is copied into a DirectBuffer before being written

We see a dramatic performance improvement for the forth test (64Mb
messages), which now takes 14seconds to complete, instead of
timeouting,  but the three first tests are going 15% slower.

2) The HeapBuffer is copied only if its suize is above XXX (XXX to be
defined)

The performances for tests 1 and 2 are the same, the 4th test is also as
good as with scenario (1), but test 2 (10Kb messages) is slowed down.


So the clear winner is scenario 2 so far.

I think I have to study a third scenario, where we only copy the buffer
if its size is above the SendBuffer size.

Also note that if the socket is not ready to accept some direct write
(for instance if there is a queue), I think the best is to convert the
HeapBuffer to a DirectBuffer.




Le 1/10/13 2:00 PM, Jeff MAURY a écrit :
> to be a little bit more precise, you will copy 64Mb the first time then
> 64Mb - 64kb the second time and so on
>
> Jeff
>
>
>
> On Thu, Jan 10, 2013 at 12:11 PM, Emmanuel Lécharny 
> <elecha...@gmail.com>wrote:
>
>> Le 1/10/13 10:56 AM, Jeff MAURY a écrit :
>>> The performance gain is not related to the nature of the buffer; I mean
>>> writing to an HeapBuffer vs writing to a DirectBuffer but related to
>>> writing the buffer to the socket: if you write an HeapBuffer to a socket,
>>> my guess is that it will be copied to a DirectBuffer before it gets
>> written
>>> to the socket which is not the case for a DirectBuffer
>> This is exactly what happens. Internally, for each call to the
>> channel.write(HeapBuffer), there is a call to DirectBuffer.pu(HeapBuffer).
>>
>> You can imagine how costly this is when the HeapBuffer is 64 Mb big, and
>> we send only a fragment of it for each round... If the SendBufferSize is
>> 64Kb, in this case, you will just copy the 64Mb 1000 times.
>>
>> Good catch btw, Jeff !
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 

Reply via email to