[jira] [Updated] (HBASE-16023) Fastpath for the FIFO rpcscheduler

["stack (JIRA)" <ji...@apache.org>]

     [ 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)