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
In both the recursor and dnsdist, we implement bounded-load load-balancing where we dispatch a query to the next bin if the selected one is full (and so on). This suffers from a "cascading overflow" effect that decreases the performance when some of the bins are getting full.
This paper 1 suggests that instead of going to the next bin, we could re-hash the already computed hash with a counter appended to it, and iterate as long as we select a full bin. This is a nice idea because that way we don't always overflow to the same bin, since different qnames will go to a second different bin when re-hashing with the counter. Using a counter also means we don't have to re-hash the whole qname, which is a bit slow.
It seems to make sense on paper, it would be nice to see if it also makes sense in our use case.
The text was updated successfully, but these errors were encountered:
In both the recursor and dnsdist, we implement bounded-load load-balancing where we dispatch a query to the next bin if the selected one is full (and so on). This suffers from a "cascading overflow" effect that decreases the performance when some of the bins are getting full.
This paper 1 suggests that instead of going to the next bin, we could re-hash the already computed hash with a counter appended to it, and iterate as long as we select a full bin. This is a nice idea because that way we don't always overflow to the same bin, since different qnames will go to a second different bin when re-hashing with the counter. Using a counter also means we don't have to re-hash the whole qname, which is a bit slow.
It seems to make sense on paper, it would be nice to see if it also makes sense in our use case.
The text was updated successfully, but these errors were encountered: