[
https://issues.apache.org/jira/browse/HBASE-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122740#comment-16122740
]
Guanghao Zhang commented on HBASE-18500:
----------------------------------------
Thanks for your explanation.
bq. The table on which put was called is created via the RegionCP env and that
uses a special Connection.
Checked the code, I thought this was introduced by HBASE-9534.
bq. For #1 we may have to use InheritableThreadLocal instead of ThreadLocal.
Agreed. But I don't know if it has any other side-effects.
bq. When doing a runAsUser, how/whether we should reset the Rpc context to have
the new user.
Do we have other scenario which need reset the Rpc context? If not, I thought
we can only fixed this for this problem. We can introduce a new config or
method to disable the "Short-Circuit Coprocessor HTable access" feature. The
code may be:
{code}
User.runAsLoginUser(new PrivilegedExceptionAction<Void>() {
@Override
public Void run() throws Exception {
// disable the "Short-Circuit Coprocessor HTable access" feature
first
// Then start a new rpc call
AccessControlLists.addUserPermission(regionEnv.getConfiguration(),
perm,
regionEnv.getTable(AccessControlLists.ACL_TABLE_NAME),
request.getMergeExistingPermissions());
return null;
}
});
{code}
> Performance issue: Don't use BufferedMutator for HTable's put method
> --------------------------------------------------------------------
>
> Key: HBASE-18500
> URL: https://issues.apache.org/jira/browse/HBASE-18500
> Project: HBase
> Issue Type: Improvement
> Reporter: Guanghao Zhang
> Assignee: Guanghao Zhang
> Attachments: HBASE-18500-v1.patch, HBASE-18500-v2.patch,
> HBASE-18500-v3.patch, HBASE-18500-v4.patch, HBASE-18500-v5.patch,
> HBASE-18500-v5.patch, HBASE-18500-v5.patch
>
>
> Copied the test result from HBASE-17994.
> Run start-hbase.sh in my local computer and use the default config to test
> with PE tool.
> {code}
> ./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=100000
> --nomapred --autoFlush=True randomWrite 1
> ./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=100000
> --nomapred --autoFlush=True asyncRandomWrite 1
> {code}
> Mean latency test result.
> || || Test1 || Test2 || Test3 || Test4 || Test5 ||
> | randomWrite | 164.39 | 161.22 | 164.78 | 140.61 | 151.69 |
> | asyncRandomWrite | 122.29 | 125.58 | 122.23 | 113.18 | 123.02 |
> 50th latency test result.
> || || Test1 || Test2 || Test3 || Test4 || Test5 ||
> | randomWrite | 130.00 | 125.00 | 123.00 | 112.00 | 121.00 |
> | asyncRandomWrite | 95.00 | 97.00 | 95.00 | 88.00 | 95.00 |
> 99th latency test result.
> || || Test1 || Test2 || Test3 || Test4 || Test5 ||
> | randomWrite | 600.00 | 600.00 | 650.00 | 404.00 | 425.00 |
> | asyncRandomWrite | 339.00 | 327.00 | 297.00 | 311.00 | 318.00 |
> In our internal 0.98 branch, the PE test result shows the async write has the
> almost same latency with the blocking write. But for master branch, the
> result shows the async write has better latency than the blocking client.
> Take a look about the code, I thought the difference is the BufferedMutator.
> For master branch, HTable don't have a write buffer and all write request
> will be flushed directly. And user can use BufferedMutator when user want to
> perform client-side buffering of writes. For the performance issue
> (autoFlush=True), I thought we can use rpc caller directly in HTable's put
> method. Thanks.
> Review: https://reviews.apache.org/r/61454/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
