-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
loadbalancer-experimental: Narrow ewma config params from long to int #2994
loadbalancer-experimental: Narrow ewma config params from long to int #2994
Conversation
Motivation: We currently allow configuring a long for the parameter values that affect the RequestTracker ewma, specifically the cancel, error, and concurrent request penalties. There are no realistic scenarios where a long is necessary vs an int. Modifications: Change the configuration parameters to an int.
...adbalancer-experimental/src/main/java/io/servicetalk/loadbalancer/DefaultRequestTracker.java
Show resolved
Hide resolved
...adbalancer-experimental/src/main/java/io/servicetalk/loadbalancer/DefaultRequestTracker.java
Outdated
Show resolved
Hide resolved
...adbalancer-experimental/src/main/java/io/servicetalk/loadbalancer/DefaultRequestTracker.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
// Add penalty for concurrent requests to account for "unaccounted" load. | ||
// Penalty is the observed latency if known, else an arbitrarily high value which makes entities for which | ||
// no latency data has yet been received (eg: request sent but not received), un-selectable. | ||
final int concurrentPenalty = (int) min(MAX_VALUE, | ||
(long) concurrentCount * concurrentRequestPenalty * currentEWMA); | ||
int concurrentPenalty = safeMultiply(concurrentCount, safeMultiply(currentEWMA, concurrentRequestPenalty)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note: when I was looking at how EWMA is calculated in updateEWMA
, it feels like if we move this part into a separate static method, it will get a higher chance for inlining:
final double tmp = (currentTimeNanos - lastTimeNanos) * invTau;
final double w = exp(-tmp);
nextEWMA = (int) ceil(currentEWMA * w + currentLatency * (1d - w));
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not strongly opinionated one way or the other, so I included it in the latest commit.
Motivation:
We currently allow configuring a long for the parameter values that affect the RequestTracker ewma, specifically the cancel, error, and concurrent request penalties. There are no realistic scenarios where a long is necessary vs an int.
Modifications:
Change the configuration parameters to an int.