[
https://issues.apache.org/jira/browse/HBASE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037498#comment-14037498
]
Andrew Purtell commented on HBASE-11355:
----------------------------------------
bq. My code has changed the scheduler by moving the queues and thread creation
in a RpcExecutor class with a SingleQueueRpcExecutor, MuliQueueRpcExecutor,
RWQueueRpcExecutor variants. It is simpler for me since I'm experimenting with
lots of different queues for HBASE-10994 and that allows me to simply create a
different instance of the RpcExecutor without keep changing the
SimpleScheduler, but I'm open for suggestion if someone wants this stuff in
0.98 or 1.0
Changing RPC internals for the sake of improving performance like this in 0.98
isn't a problem as long as public interfaces (including coprocessor related)
are not touched. If that happens, then we'd want to do a case by case
evaluation.
I looked at the attached patch and find no reason why it, and its prerequisite
changes, could not go into 0.98. It would be good to have an opportunity to try
it. If we find a significant regression during release candidate validation we
can revert.
> a couple of callQueue related improvements
> ------------------------------------------
>
> Key: HBASE-11355
> URL: https://issues.apache.org/jira/browse/HBASE-11355
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC, Performance
> Affects Versions: 0.99.0, 0.94.20
> Reporter: Liang Xie
> Assignee: Matteo Bertozzi
> Attachments: HBASE-11355-v0.patch
>
>
> In one of my in-memory read only testing(100% get requests), one of the top
> scalibility bottleneck came from the single callQueue. A tentative sharing
> this callQueue according to the rpc handler number showed a big throughput
> improvement(the original get() qps is around 60k, after this one and other
> hotspot tunning, i got 220k get() qps in the same single region server) in a
> YCSB read only scenario.
> Another stuff we can do is seperating the queue into read call queue and
> write call queue, we had done it in our internal branch, it would helpful in
> some outages, to avoid all read or all write requests ran out of all handler
> threads.
> One more stuff is changing the current blocking behevior once the callQueue
> is full, considering the full callQueue almost means the backend processing
> is slow somehow, so a fail-fast here should be more reasonable if we using
> HBase as a low latency processing system. see "callQueue.put(call)"
--
This message was sent by Atlassian JIRA
(v6.2#6252)
