-
Notifications
You must be signed in to change notification settings - Fork 53
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
Epsilon-Greedy seems an odd choice for a load-balancer #2
Comments
Interesting. This does sounds like it might have some useful properties. I'd love to see how this works out if you get a prototype implemented. The Epsilon-Greedy is certainly an experiment, and it's on our to-do list to describe some of how that has worked in a few select cases at bitly. There are lots of cases where it's useless, but we've found at least one where it's very valuable. |
Since epsilon greedy already has all the time tracking, the 'easiest' way to prototype this is just to directly replace the loop that does the selection that begins "if len(possibleHosts) != 0" near epsilon_greedy.go:130 . Note this is completely untested, but it does compile :)
I'll unfortunately be unable to tes this further right now. I won't have time to play with this until closer to the end of May. |
Just realized I never came back to play with this. I still think this change makes sense. Not sure how to test this to see if it actually gives more evenly distributed load though.. |
I would have assumed "two random choices" would have given a better lower average load.
Given that you're already tracking latency information for epsilon-greedy, implementing two random choices should be fairly straight-forward.
For more information on "two random choices", see http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf .
The text was updated successfully, but these errors were encountered: