You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Enis Soztutar (JIRA)" <ji...@apache.org> on 2014/07/11 02:01:10 UTC
[jira] [Updated] (HBASE-11492) The servers do not honor the
tcpNoDelay option
[ https://issues.apache.org/jira/browse/HBASE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Enis Soztutar updated HBASE-11492:
----------------------------------
Summary: The servers do not honor the tcpNoDelay option (was: The servers do not honnor the tcpNoDelay option)
> 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)