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

Andrew Kyle Purtell commented on HBASE-23649:
---------------------------------------------

> A naive way is to double the fan out at each attempt (starting from 1) until 
> we reach the configured max fan out. For example if the max fan out is 10, 
> instead of bursting to all 10 in each attempt, we fan out with values 1, 2, 
> 4, 8, 10, 10, 10...

This strategy is a time honored tradition. Most TCP stacks implement 
exponential backoff using a simple array of multipliers just so. I prefer 
simple solutions first, so this seems reasonable to me, or you can consider a 
flatter curve like 1, 2, 3, 5, 8, 10, 10, ... 

> Implement an adaptive hedging policy 
> -------------------------------------
>
>                 Key: HBASE-23649
>                 URL: https://issues.apache.org/jira/browse/HBASE-23649
>             Project: HBase
>          Issue Type: New Feature
>          Components: Client, rpc
>    Affects Versions: 3.0.0
>            Reporter: Bharath Vissapragada
>            Assignee: Bharath Vissapragada
>            Priority: Major
>
> HBASE-23305 implements a new rpc channel that can hedge requests to multiple 
> target end points. As [~andrew.purt...@gmail.com] noted in the code review, 
> it makes more sense to have a pluggable hedging policy and make it adaptive 
> based on certain rpc performance/success metrics. 
> By default, the implementation hedges the requests across 'n' target 
> addresses. However in most cases, for smaller rpcs, the first 1 or 2 end 
> points should return the results pretty quickly  and there is no point in 
> hedging with a bigger fan out as that only increases the load on the target 
> servers. The idea is to increase the fan out only when needed. 
> A naive way is to double the fan out at each attempt (starting from 1) until 
> we reach the configured max fan out. For example if the max fan out is 10, 
> instead of bursting to all 10 in each attempt, we fan out with values 1, 2, 
> 4, 8, 10, 10, 10...
> Any suggestions welcome.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to