[
https://issues.apache.org/jira/browse/HBASE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14103902#comment-14103902
]
Hudson commented on HBASE-11355:
--------------------------------
FAILURE: Integrated in HBase-1.0 #115 (See
[https://builds.apache.org/job/HBase-1.0/115/])
HBASE-11737 Document callQueue improvements from HBASE-11355 and HBASE-11724
(Misty Stanley-Jones) (matteo.bertozzi: rev
5c1ae840f21f7a3857543e408ef20a63be2b0751)
* src/main/docbkx/performance.xml
> 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
> Fix For: 0.99.0, 0.98.4
>
> Attachments: HBASE-11355-v0.patch, HBASE-11355-v1.patch,
> HBASE-11355-v2.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)
