hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amit Patel (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18542) [HLC] Performance microbenchmarks
Date Fri, 25 Aug 2017 17:38:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141932#comment-16141932

Amit Patel commented on HBASE-18542:

I redid the benchmarks using JMH as suggested [~enis] (thanks for the examples!). I ran tests
on Clock#now and Clock#update for each clock implementation with 1, 4, and then 16 threads.
The hybrid logical clock implementation doesn't look too good and does not scale with additional
threads compared to the system and system monotonic clock implementation. The main culprit
is the use of the synchronized blocks in the HLC's Clock#now and Clock#update so these results
would represent the worst case. 

Overall, there is still work that needs to be done to improve performance for the hybrid logical
clock implementation.

> [HLC] Performance microbenchmarks
> ---------------------------------
>                 Key: HBASE-18542
>                 URL: https://issues.apache.org/jira/browse/HBASE-18542
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Appy
>            Assignee: Amit Patel
>         Attachments: HBASE-18542.HBASE-14070.HLC.001.patch
> Need tests to benchmark performance of Clock#now() and update() functions (for all types
of clocks).
> If update() is too costly, we can do optimizations in ExecuteProceduresRemoteCall#call(),
HRegion#replayRecoveredEdits() and other places where we call update() in loop. Instead, it
might be faster to calculate max timestamp in loop and call update() just once.

This message was sent by Atlassian JIRA

View raw message