[ 
https://issues.apache.org/jira/browse/FLINK-15963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

zhijiang updated FLINK-15963:
-----------------------------
    Description: 
On sender side while writing the BufferResponse message, it always allocates 
the new direct ByteBuf from netty allocator to write header part for every 
message.

Maybe we can maintain a fixed ByteBuf per channel and make use of it to write 
header part for all the BufferResponse messages, then verify how it effects the 
performance/memory overhead in e2e/benchmark.

This improvement is also related to another argue that whether it is feasible 
to suspend writing when the socket is not writable at the moment.  If the 
socket is not writable temporarily, the server handler would continue writing & 
flushing BufferResponse messages until reaching the maximum watermark in netty 
stack. And only the header ByteBuf would occupy the netty watermark at the 
moment.

  was:
On sender side while writing the BufferResponse message, it always allocates 
the new direct ByteBuf from netty allocator to write header part for every 
message.

Maybe we can make use of a fixed ByteBuf to write header part for all the 
BufferResponse messages, then verify how it effects the performance/memory 
overhead in e2e/benchmark.


> Reuse the same ByteBuf while writing the BufferResponse header
> --------------------------------------------------------------
>
>                 Key: FLINK-15963
>                 URL: https://issues.apache.org/jira/browse/FLINK-15963
>             Project: Flink
>          Issue Type: Improvement
>          Components: Runtime / Network
>            Reporter: zhijiang
>            Priority: Major
>
> On sender side while writing the BufferResponse message, it always allocates 
> the new direct ByteBuf from netty allocator to write header part for every 
> message.
> Maybe we can maintain a fixed ByteBuf per channel and make use of it to write 
> header part for all the BufferResponse messages, then verify how it effects 
> the performance/memory overhead in e2e/benchmark.
> This improvement is also related to another argue that whether it is feasible 
> to suspend writing when the socket is not writable at the moment.  If the 
> socket is not writable temporarily, the server handler would continue writing 
> & flushing BufferResponse messages until reaching the maximum watermark in 
> netty stack. And only the header ByteBuf would occupy the netty watermark at 
> the moment.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to