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

Andrew Kyle Purtell edited comment on HBASE-23649 at 1/9/20 8:15 PM:
---------------------------------------------------------------------

bq. 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, ... 


was (Author: apurtell):
> 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