[
https://issues.apache.org/jira/browse/HBASE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044194#comment-14044194
]
stack commented on HBASE-11355:
-------------------------------
Could we have a version that is basic and that makes factor * handler count
queues where factor is a number we decide on, say 1/5th or 1/10th. The idea is
that this facility is on by default and that user does not have to do
configuration to get the basics working. Should they later want to play w/
queue counts, then they can mess with configs setting up explicity queue number
and/or read vs write proportions.
I took a look at the patch, lgtm. One day we should sweep through the code
base and just make a Random per handler or so rather than create an instance
per usage. Later.
On:
+ // TODO: Is there a better way to do this?
... yeah... but it ain't too bad. You are narrowing when you do the
interrogation and then you are looking for the Mutation marker Interface so not
too fragile.
On your model for plugging in different RpcExecutors, its good.
Make info level:
+ LOG.debug("Using " + callQueueType + " as user call queue, count=" +
numCallQueues);
This is pretty important info...
This is good:
- return callQueue.size();
+ return callExecutor.getQueueLength();
Its great [~mbertozzi]
> 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, gets.png
>
>
> 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)
