- From: N.G.Smith <ngs@sesame.hensa.ac.uk>
- Date: Tue, 18 Jun 1996 14:06:59 +0100
- To: S.N.Brodie@ecs.soton.ac.uk
- Cc: www-proxy@w3.org
>I've implemented a load-balancing scheme whereby when the initial DNS >lookup is done for wwwcache.hensa.ac.uk, all 4 IP addresses are added to >my internal cache. This buffer is then rotated every time the table is >consulted, and upon certain types of connection failure, a retry with a >different address is used and the failed address removed from the address >cache, until such a time as there are none left, at which point a new DNS >lookup will be performed. However, there is no fallback to using the >direct connection to target host yet. > >Is this the right sort of strategy to be following? It certainly seems to >work, but it's hard to test the resilience without a partial failure of >the cache. > >Stewart Brodie, Electronics & Computer Science, Southampton University. This addresses some of the resilience issues, however, going direct in the case where all proxies fail would add that little bit more. The HENSA caches are distributed at different physical locations so a network failure is unlikely to affect all the HENSA machines without affecting SuperJANET as a whole, but it is possible. Something else you might want to consider is measuring the responsiveness of each of the machines. Migrating to the machine(s) that give best responsiveness might help to balance the load. Having said that, this would interfere with the load balancing we do on the server side. You might also like to consider some kind of timeout on receiving data from the proxy. I have seen a failure mode where the proxy picks up the connection, but then does nothing with it. Netscape v2 has no such timeout, so a user in this case is left watching a blank page, when there are other proxies available. Neil Smith HENSA Unix
Received on Tuesday, 18 June 1996 09:08:00 UTC