[
https://issues.apache.org/jira/browse/HBASE-23113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076674#comment-17076674
]
Mark Robert Miller edited comment on HBASE-23113 at 4/6/20, 9:13 PM:
---------------------------------------------------------------------
I've put up a new pull request and spent a good amount of time looking for any
negative results to the tests with these changes - so far I don't see any.
* WRITE_BUFFER_WATER_MARK
This is a good Netty feature that I think certainly makes sense to expose. It
could be disabled by default, but personally I'd see setting it by default as a
nice improvement as well.
* SO_REUSEADDR
This is a useful feature for good restart behavior as mentioned above, often
very helpful in tests as much or more than production as they may restart
things very quickly and the speed/behavior of that can be hardware/OS dependent.
* SO_BACKLOG
I don't like increasing queue sizes as a default stance, but this one is known
to improve things when connection management life cycle is often off and/or
connection reuse is not great, or lot's of retries, etc. It's also nice to pin
it in HBase config vs relying on changing/varying external defaults. Given what
I've seen of HBase, I think raising the default here is a good idea, but again,
could default to previous behavior and just allow configuration as well.
was (Author: markrmiller):
I've put up a new pull request and spent a good amount of time looking for any
negative results to the tests with these changes - so far I don't see any.
* WRITE_BUFFER_WATER_MARK
This is a good Netty feature that I think certainly makes sense to expose. It
could be disabled by default, but personally I'd see setting it by default as a
nice improvement as well.
* SO_REUSEADDR
This is a useful feature for good restart behavior as mentioned above, often
very helpful in tests as much or more than production as they may restart
things very quickly and the speed/behavior of that can be hardware/OS dependent.
* SO_BACKLOG
I don't like increasing queue sizes as a default stance, but this one is known
to improve things when connection management cycle is often off and/or
connection reuse is not great, or lot's of retries, etc. It's also nice to pin
it in HBase config vs relying on changing/varying external defaults. Given what
I've seen of HBase, I think raising the default here is a good idea, but again,
could default to previous behavior and just allow configuration as well.
> IPC Netty Optimization
> ----------------------
>
> Key: HBASE-23113
> URL: https://issues.apache.org/jira/browse/HBASE-23113
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC
> Reporter: Nicholas Jiang
> Assignee: Nicholas Jiang
> Priority: Minor
> Attachments: Decoder.jpeg
>
>
> Netty options in IPC Server/Client optimization:
> 1.SO_BACKLOG setting:Two queues are maintained in the Linux system kernel:
> syns queue and accept queue. The first is a semi-join queue that saves the
> connections to the synrecv state after receiving the client syn. The default
> netty is 128,io.netty.util.NetUtil#SOMAXCONN , and then read
> /proc/sys/net/core /somaxconn to continue to determine, and then there are
> some system level coverage logic.In some scenarios, if the client is far
> redundant to the server and the connection is established, it may not be
> enough. This value should not be too large, otherwise it will not prevent
> SYN-Flood attacks. The current value has been changed to 1024. After setting,
> the value set by yourself is equivalent to setting the upper limit because of
> the setting of the system and the size of the system. If some settings of the
> Linux system operation and maintenance are wrong, it can be avoided at the
> code level.At present, our Linux level is usually set to 128, and the final
> calculation will be set to 128.
> 2.WRITE_BUFFER_WATER_MARK setting:After WRITEBUFFERWATERMARK sets the maximum
> and minimum Buffer that can be temporarily stored on a connection, isWritable
> returns unwritable if the amount of data waiting to be sent for the
> connection is greater than the set value. In this way, the client can no
> longer send, preventing this amount of continuous backlog, and eventually the
> client may hang. If this happens, it is usually caused by slow processing on
> the server side. This value can effectively protect the client. At this point
> the data was not sent.
> 3.SO_REUSEADDR - Port multiplexing (allowing multiple sockets to listen on
> the same IP+ port): For time-wait links, it ensures that the server restarts
> successfully. In the case where some servers start up very quickly, it can
> prevent startup failure.
> Netty decoder in IPC Server optimization:
> Netty provides a convenient decoding tool class ByteToMessageDecoder, as
> shown in the top half of the figure, this class has accumulate bulk unpacking
> capability, can read bytes from the socket as much as possible, and then
> synchronously call the decode method to decode the business object. And
> compose a List. Finally, the traversal traverses the List and submits it to
> ChannelPipeline for processing. Here we made a small change, as shown in the
> bottom half of the figure, the content to be submitted is changed from a
> single command to the entire List, which reduces the number of pipeline
> executions and improves throughput. This mode has no advantage in
> low-concurrency scenarios, and has a significant performance boost in boost
> throughput in high-concurrency scenarios.
> !Decoder.jpeg!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
