[ 
https://issues.apache.org/jira/browse/HBASE-8836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733797#comment-13733797
 ] 

Devaraj Das commented on HBASE-8836:
------------------------------------

Overall, seems like a good improvement. Some high level comments.
1. We need a patch for trunk before we can commit this in 0.94.x
2. Can we look at annotations (similar to QoS annotation) for marking which 
methods should be treated as READ vs WRITE. That way we can keep the RPC code 
intact and have to only play with annotations on methods in the future.
3. Other comments are around code duplication that others have talked about 
already (in trunk it's better since the SecureRPCEngine doesn't exist there), 
and maybe we should keep the original getServer method, and it should do what 
it does currently (without the patch).
                
> Separate reader and writer thread pool in RegionServer, so that write 
> throughput will not be impacted when the read load is very high
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-8836
>                 URL: https://issues.apache.org/jira/browse/HBASE-8836
>             Project: HBase
>          Issue Type: New Feature
>          Components: Performance, regionserver
>    Affects Versions: 0.94.8
>            Reporter: Tianying Chang
>            Assignee: Tianying Chang
>             Fix For: 0.98.0, 0.94.12
>
>         Attachments: hbase-8836.patch, Hbase-8836-perfNumber.pdf
>
>
> We found that when the read load on a specific RS is high, the write 
> throughput also get impacted dramatically, and even cause write data loss 
> sometimes. We want to prioritize the write by putting them in a separate 
> queue from the read request, so that slower read will not make fast write 
> wait nu-necessarily long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to