[
https://issues.apache.org/jira/browse/HBASE-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580421#comment-13580421
]
Lars Hofhansl commented on HBASE-7868:
--------------------------------------
Looking at the other tests in PerformanceEvaluation I don't get what it is
actually useful for. The RandomReadTest send single Gets to the server(s) so it
is mostly the network RTT. Similarly scanner cache is set to 30, which also
means that for the scan tests we're mostly measuring the network.
OK... I am less worried now :)
[~yuzhih...@gmail.com] That might be a good idea. In the end I am not sure it
is worth it, though. For most folks these metrics will (IMHO) more important
than a 2.5% performance gain (and it's only 2.5% if all rows are filtered out
at the server, much less percentage-wise if we actually returned data to the
client).
That said, we should try to make collection of these metrics better (lazy or
approximate as Andy also suggests).
> HFile performance regression between 0.92 and 0.94
> --------------------------------------------------
>
> Key: HBASE-7868
> URL: https://issues.apache.org/jira/browse/HBASE-7868
> Project: HBase
> Issue Type: Bug
> Components: io
> Affects Versions: 0.94.5
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Fix For: 0.94.6
>
> Attachments: FilteredScan.png, hfileperf-graphs.png, performances.pdf
>
>
> By HFilePerformanceEvaluation seems that 0.94 is slower then 0.92
> Looking at the profiler for the Scan path, seems that most of the time,
> compared to 92, is spent in the metrics dictionary lookup. [~eclark] pointed
> out the new per family/block metrics.
> By commenting the metrics call in HFileReaderV2, the performance seems to get
> better, but maybe metrics is not the only problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
