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

Srikanth Srungarapu commented on HBASE-14205:
---------------------------------------------

bq.  We could also turn it off with a config toggle I suppose and see if 
someone complains about a functional regression. We'd doc in release notes how 
to turn it back on. In any case, why not just remove this entirely from 1.2 and 
up? 
Both suggestions good to me. Just to be sure, for 1.2 and above, the plan is to 
remove this feature entirely. And for the earlier versions, it is to turn if 
off with the help of config switch. I'll put up a patch for the same unless 
anyone has concerns.

> 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 worse.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to