On 7/1/22 8:22 AM, Théo BARRAGUE wrote:
If *link a* slows down, the RTT will increase and *squid* will send all requests to *squid b* because his RTT is low. But, if *link a* come back and with a lower RTT than *squid b*, *squid a* will never know because no requests are made to him until RTT on *squid b* goes up ( upper than the "uppest" / "oldest" RTT of *squid a* ).How to deal with this scenario ?
I have no idea if this will help you or not but this problem seems reminiscent of DNS servers (e.g. BIND/named) deal with multiple potential servers.
My loose understanding is that BIND/named will /artificially/ alter the cached RTT /explicitly/ to make sure that abnormally high / low values don't negatively impact things. I think there are a couple of ways to do this:
1) Artificially decrease the RTT incrementally or based on it's age (last seen) so that an originally high RTT value lowers enough that it becomes a candidate to be used again. -- If it turns out that the RTT still really is high then the RTT will get updated back to it's high value and thus depreffed.
2) Artificially increase the RTT incrementally, perhaps one point per test, so that the originally low RTT value raises enough that is higher than the other candidate, thus deprefed.
This turns into a balancing game, artificially adjust the RTT so that a system is (not) chosen thereby choosing the other system, which updates the values.
I think which method is used is probably based on what works best in the code.
But one of these should cause some small portion of traffic to go to the deprefed server explicitly to keep it's RTT up to date.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
