[
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 [[email protected]] 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)
