[
https://issues.apache.org/jira/browse/HBASE-18542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141932#comment-16141932
]
Amit Patel edited comment on HBASE-18542 at 8/25/17 5:54 PM:
-------------------------------------------------------------
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.
Results:
https://docs.google.com/spreadsheets/d/1ndAVSwQ4yBqqu28_9eREg9qqDrpcXVt7TfTJOQWUq8Q/edit?usp=sharing
Overall, there is still work that needs to be done to improve performance for
the hybrid logical clock implementation.
was (Author: amit.patel):
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.
https://docs.google.com/spreadsheets/d/1ndAVSwQ4yBqqu28_9eREg9qqDrpcXVt7TfTJOQWUq8Q/edit?usp=sharing
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
(v6.4.14#64029)
