hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay T <jay.pyl...@gmail.com>
Subject Re: Inconsistent scan performance with caching set to 1
Date Thu, 30 Aug 2012 16:24:09 GMT
  Thanks Stack for pointing us in the right direction. Indeed it was the 
tcpNodeDelay setting. We set these to be true.

ipc.server.tcpnodelay ==> true
hbase.ipc.client.tcpnodelay ==> true

All reads that previously had the 40ms overhead are now between 2 and 3 
ms like we would expect them to be.

Are these settings worthy of being put in the Hbase online book  ?


On 8/30/12 2:07 AM, Stack wrote:
> On Wed, Aug 29, 2012 at 10:42 AM, Wayne<wav100@gmail.com>  wrote:
>> This is basically a read bug/performance problem. The execution path
>> followed when the caching is used up is not consistent with the initial
>> execution path/performance. Can anyone help shed light on this? Was there
>> any changes to 0.94 to introduce this (we have not tested on other
>> versions)? Any help or advice would be appreciated. As it is stands we are
>> looking to have to reverse engineer every aspect of a read from both the
>> hbase client and server components to find and fix.
>> One additional lead is that not all rows behave like this. Only certain
>> small rows seem to do this consistently. Most of our rows are larger and do
>> not have this behavior.
> Nagles?  (https://issues.apache.org/jira/browse/HBASE-2125)
> St.Ack

View raw message