You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing WRR LB uses a per-thread EDF scheduler. This makes memory usage O(m * n) where m is the number of hosts and n the number of endpoints. We can shrink this to O(n * w), where w is the weight range, if we precompute the schedule on the main thread (as we do for consistent hash balancers) and just maintain an index that we rotate around the shared schedule for WRR. This comes at the downside of increased memory use when we have a wide range of weights, but as long as we maintain a limited set of weights (which we need to do anyway to sanely support locality weighting with the consistent hash balancers), this should be reasonable.
The text was updated successfully, but these errors were encountered:
@alyssawilk points out that this might not do brilliantly as the number of hosts scales if we want the full range of weights preserved, and that what we do today with the consistent hash schemes is also problematic. We should explore these tradeoffs more thoroughly before committing to a specific implementation path here.
The existing WRR LB uses a per-thread EDF scheduler. This makes memory usage O(m * n) where m is the number of hosts and n the number of endpoints. We can shrink this to O(n * w), where w is the weight range, if we precompute the schedule on the main thread (as we do for consistent hash balancers) and just maintain an index that we rotate around the shared schedule for WRR. This comes at the downside of increased memory use when we have a wide range of weights, but as long as we maintain a limited set of weights (which we need to do anyway to sanely support locality weighting with the consistent hash balancers), this should be reasonable.
The text was updated successfully, but these errors were encountered: