[ https://issues.apache.org/jira/browse/HBASE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058307#comment-14058307 ]
Liang Xie commented on HBASE-11492: ----------------------------------- I have no more knowledge on this area, but i could not convince me to believe the original "socket().setTcpNoDelay" style did not take effect, since HDFS + HBase always use this style, right? so weird, my god... > The servers do not honor the tcpNoDelay option > ---------------------------------------------- > > Key: HBASE-11492 > URL: https://issues.apache.org/jira/browse/HBASE-11492 > Project: HBase > Issue Type: Bug > Components: regionserver > Affects Versions: 0.92.2, 0.98.0, 0.96.0, 0.99.0, 0.94.20 > Reporter: Nicolas Liochon > Assignee: Nicolas Liochon > Priority: Critical > Fix For: 0.99.0, 0.98.5 > > Attachments: 11492.v1.patch > > > There is an option to set tcpNoDelay, defaulted to true, but the socket > channel is actually not changed. As a consequence, the server works with > nagle enabled. This leads to very degraded behavior when a single connection > is shared between threads. We enter into conflicts with nagle and tcp delayed > ack. > Here is an example of performance with the PE tool plus HBASE-11491: > {noformat} > oneCon #client sleep exeTime (seconds) > avg latency, sleep excluded (microseconds) > true 1 0 31 > 310 > false 1 0 31 > 310 > true 2 0 50 > 500 > false 2 0 31 > 310 > true 2 5 488 (including 200s sleeping) > 2880 > false 2 5 246 (including 200s sleeping) > 460 > {noformat} > The latency is multiple by 5 (2880 vs 460) when the connection is shared. > This is the delayed ack kicking in. This can be fixed by really using tcp no > delay. > Any application sharing the tcp connection between threads has the issue. -- This message was sent by Atlassian JIRA (v6.2#6252)