-
Notifications
You must be signed in to change notification settings - Fork 0
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
WIP: Make Load Balancer Prefer a Lookback Of Recent Invokers for an Action #2
base: master
Are you sure you want to change the base?
Conversation
...er/src/main/scala/org/apache/openwhisk/core/loadBalancer/ShardingContainerPoolBalancer.scala
Outdated
Show resolved
Hide resolved
//filter out invokers that would represent an activation over 10 minutes old | ||
val validActionLastInvokers = | ||
actionLastInvokers.filter(invokerWithTimestamp => Instant.now.toEpochMilli - invokerWithTimestamp._2 < 600000) | ||
if (validActionLastInvokers.size < maxRecentInvokers) { |
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.
What is the reason for having this case?
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.
It's to bootstrap by using the home invoker algorithm. This method won't kick in in making scheduling decisions until you have the n lookback activations completed in the last ten minutes for the action.
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 thinking there should be two dials then, a min number of activations completed before making scheduling decisions with the lookback and also a max number of invokers to keep in the lookback queue.
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.
Yea I thought of something similar where you don't include the invoker in the final list unless the number of occurrences in the queue is over some ratio threshold. Is the concern that say the queue has three invokers in it with a max lookback of ten. Invoker 0 has 6 occurrences, invoker 1 has 3 occurrences, and invoker2 has 1 occurrence. You're thinking that invoker2 shouldn't be included in the returned list because the number of occurrences is too low right? I don't think that should affect things too much because the invokers it uses are still going to be bootstrapped off the home invoker algorithm and the same steps and it still prefers the most frequent as in it will try 0, then 1, then 2, and then go back to home invoker stepping. I don't think that should affect things really for an initial test
if (preferredInvoker.nonEmpty) { | ||
preferredInvoker.get | ||
} else { | ||
schedule(maxConcurrent, fqn, invokers, dispatched, slots, index, step, stepsDone + 1) | ||
} |
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.
nit: preferredInvoker.getOrElse(schedule)
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 had that originally, it surprisingly doesn't compile because of the way @tailrec
works
...er/src/main/scala/org/apache/openwhisk/core/loadBalancer/ShardingContainerPoolBalancer.scala
Outdated
Show resolved
Hide resolved
ed5643a
to
7672f08
Compare
9d14534
to
bd4d062
Compare
Description
Related issue and scope
My changes affect the following components
Types of changes
Checklist: