Skip to content
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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

bdoyle0182
Copy link
Collaborator

Description

Related issue and scope

  • I opened an issue to propose and discuss this change (#????)

My changes affect the following components

  • API
  • Controller
  • Message Bus (e.g., Kafka)
  • Loadbalancer
  • Invoker
  • Intrinsic actions (e.g., sequences, conductors)
  • Data stores (e.g., CouchDB)
  • Tests
  • Deployment
  • CLI
  • General tooling
  • Documentation

Types of changes

  • Bug fix (generally a non-breaking change which closes an issue).
  • Enhancement or new feature (adds new functionality).
  • Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

  • I signed an Apache CLA.
  • I reviewed the style guides and followed the recommendations (Travis CI will check :).
  • I added tests to cover my changes.
  • My changes require further changes to the documentation.
  • I updated the documentation where necessary.

//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) {

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?

Copy link
Collaborator Author

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.

Copy link

@quintenp01 quintenp01 Jan 8, 2021

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.

Copy link
Collaborator Author

@bdoyle0182 bdoyle0182 Jan 9, 2021

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

Comment on lines 454 to 459
if (preferredInvoker.nonEmpty) {
preferredInvoker.get
} else {
schedule(maxConcurrent, fqn, invokers, dispatched, slots, index, step, stepsDone + 1)
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: preferredInvoker.getOrElse(schedule)

Copy link
Collaborator Author

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

@bdoyle0182 bdoyle0182 force-pushed the scheduling-invoker-lookback branch from ed5643a to 7672f08 Compare January 11, 2021 18:37
@bdoyle0182 bdoyle0182 force-pushed the scheduling-invoker-lookback branch from 9d14534 to bd4d062 Compare January 27, 2021 22:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants