[
https://issues.apache.org/jira/browse/HBASE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-11355:
------------------------------------
Attachment: HBASE-11355-v1.patch
[~stack] something like this?
* ipc.server.callqueue.handler.factor
** Factor to determine the number of call queues. (callq.factor *
handlers.count)
** A value of 0 means a single queue shared between all the handlers.
** A value of 1 means that each handler has its own queue.
** A value of 0.5 means that each 2 handlers share the same queue
** A value > 1 will add more handlers, num queues = num handlers
* ipc.server.callqueue.read.share</name>
** Split the call queues into read and write queues.
** A value of 0 indicate to not split the call queues.
** A value of 0.5 means there will be the same number of read and write
queues
** A value of 1.0 (or more) means that all the queues except one are used
to dispatch read requests.
the defaults are 0, which means single queue as before. or do you want bump the
"ipc.server.callqueue.handler.factor" default to use more than one queue?
> 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, HBASE-11355-v1.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)
