[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14205: Component/s: regionserver Coprocessors > RegionCoprocessorHost System.nanoTime() performance bottleneck > -- > > Key: HBASE-14205 > URL: https://issues.apache.org/jira/browse/HBASE-14205 > Project: HBase > Issue Type: Bug > Components: Coprocessors, Performance, regionserver >Reporter: Jan Van Besien >Assignee: Andrew Purtell >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14205.patch > > > 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14205: Component/s: Performance > RegionCoprocessorHost System.nanoTime() performance bottleneck > -- > > Key: HBASE-14205 > URL: https://issues.apache.org/jira/browse/HBASE-14205 > Project: HBase > Issue Type: Bug > Components: Coprocessors, Performance, regionserver >Reporter: Jan Van Besien >Assignee: Andrew Purtell >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14205.patch > > > 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14205: Labels: needs_releasenote (was: ) > RegionCoprocessorHost System.nanoTime() performance bottleneck > -- > > Key: HBASE-14205 > URL: https://issues.apache.org/jira/browse/HBASE-14205 > Project: HBase > Issue Type: Bug > Components: Coprocessors, Performance, regionserver >Reporter: Jan Van Besien >Assignee: Andrew Purtell >Priority: Critical > Labels: needs_releasenote > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14205.patch > > > 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14205: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch-1.2, branch-1, and master. Thanks for the review Srikanth. > 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 >Assignee: Andrew Purtell >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14205.patch > > > 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14205: --- Status: Patch Available (was: Open) > 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 >Assignee: Andrew Purtell >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14205.patch > > > 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14205: --- Attachment: HBASE-14205.patch Patch for master completely removes APIs and UI widget > 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 >Assignee: Andrew Purtell >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14205.patch > > > 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14205: -- Priority: Critical (was: Major) 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 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 row (prePut, postPut, postStartRegionOperation and postCloseRegionOperation) which has 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Van Besien updated HBASE-14205: --- Description: 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. was: 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 row (prePut, postPut, postStartRegionOperation and postCloseRegionOperation) which has 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. 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 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)
[jira] [Updated] (HBASE-14205) RegionCoprocessorHost System.nanoTime() performance bottleneck
[ https://issues.apache.org/jira/browse/HBASE-14205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-14205: --- Fix Version/s: 1.3.0 1.2.0 2.0.0 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)
