feat: add penalty for nodes unavailability in latency-based routing #587
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In the current implementation of the latency-based routing, the probability of choosing a node as a routing
URL
is proportional to the node's score. The score is calculated as an inverse value of the moving average of latency measurements over some sliding window. Hence, nodes with smaller latencies produce higher score values and are more likely to be selected. However, in the current approach when a node was unavailable (within the sliding window), it was completely removed from routing. This was a "harsh" punishment, which is not always optimal, as latency can experience sporadic spikes.In this PR we introduce a more sophisticated and customizable way of calculating node's score, where the combination of node's latency and availability are used to produce the final score. Node's score is now penalized, if it was unavailable within the sliding window measurements and not set to zero as before. A node is only removed from routing if it was unavailable in the last measurement.
Approach:
availabilities
andlatencies
for each nodeNote that inverse of latency is used to produce higher scores for smaller latencies.
This allows to take recency factor into account, i.e. more recent observations contribute to the score with higher weights.$w_i=1$ could be provided as input.
Note, users can also provide their custom
weights
. For example, to exclude recency factor, allThis allows to emphasize the importance of both metrics in the final score.
Example:
How Has This Been Tested?
Additional tests in
latency_based_routing.rs
have been introduced.Checklist: