[ https://issues.apache.org/jira/browse/HBASE-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HBASE-11355: -------------------------- Attachment: gets.png Random reads per second. First hump is w/o patch. Second hump is w/ patch and config applied. Here is what I ran: for i in c2020 c2022 c2023 c2024 c2025; do echo $i; ssh $i "nohup ./hbase-0.99.0-SNAPSHOT/bin/hbase --config ~/conf_hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --size=2.0 randomRead 30 > pe.out 2> pe.err < /dev/null &"; done > 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)