[
https://issues.apache.org/jira/browse/HBASE-16023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-16023:
--------------------------
Attachment: hits.nofifo.fifoplusfp.fifownofp.hacks.png
Graph with four humps. We are doing workloadc here with 8 nodes doing
asynchbase ycsb against a single regionserver instance.
The first hump is current tip of branch-1 ops... about 210k ops a second.
The second hump is w/ the fix for HBASE-15971 in place -- i.e. we are doing
fifo rpcscheduler by default -- PLUS this patch.
Third hump is just HBASE-15971 in place.
Fourth (and fifth humps) are me messing hacking out HBASE-15716 and the Store
scanner registering of listeners. We are bottlenecked on returning results by
the time we get to the extreme right hand side of the graph.
> Fastpath for the FIFO rpcscheduler
> ----------------------------------
>
> Key: HBASE-16023
> URL: https://issues.apache.org/jira/browse/HBASE-16023
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: stack
> Assignee: stack
> Attachments: hits.nofifo.fifoplusfp.fifownofp.hacks.png
>
>
> This is an idea copied from kudu where we skip queuing a request if there is
> a handler ready to go; we just do a direct handoff from reader to handler.
> Makes for close to a %20 improvement in random read workloadc testing moving
> the bottleneck to HBASE-15716 and to returning the results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
