[squid-users] How to "active" update NetDB informations ?
Grant Taylor
gtaylor at tnetconsulting.net
Fri Jul 1 20:38:48 UTC 2022
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220701/2c6ad551/attachment.bin>
More information about the squid-users
mailing list