hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
Date Tue, 11 Aug 2015 18:56:47 GMT

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

Andrew Purtell commented on HBASE-14205:

On HBASE-13420 the suggestion (from John Leach) was remove entirely. I agree with that approach,
but Srikanth and I both thought that would amount to a functional regression if done in a
patch release. Yeah, the 'function' is a performance concern. The remainder of the issue focused
on mitigating John's issue. We could also turn it off with a config toggle I suppose and see
if someone complains about a functional regression. In any case, why not just remove this
entirely from 1.2 and up? 

> RegionCoprocessorHost System.nanoTime() performance bottleneck
> --------------------------------------------------------------
>                 Key: HBASE-14205
>                 URL: https://issues.apache.org/jira/browse/HBASE-14205
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Jan Van Besien
>            Priority: Critical
>             Fix For: 2.0.0, 1.2.0, 1.3.0
> The tracking of execution time of coprocessor methods introduced in HBASE-11516 introduces
2 calls to System.nanoTime() per coprocessor method per coprocessor. This is resulting in
a serious performance bottleneck in certain scenarios.
> For example consider the scenario where many rows are being ingested (PUT) in a table
which has multiple coprocessors (we have up to 20 coprocessors). This results in 8 extra calls
to System.nanoTime() per coprocessor (prePut, postPut, postStartRegionOperation and postCloseRegionOperation)
which has in total (i.e. times 20) been seen to result in a 50% increase of execution time.
> I think it is generally considered bad practice to measure execution times on such a
small scale (per single operation). Also note that measurements are taken even for coprocessors
that do not even have an actual implementation for certain operations, making the problem

This message was sent by Atlassian JIRA

View raw message