On Thursday 06 March 2003 19.04, Ard van Breemen wrote: > I can only think of one reason not to do it, and that is the > failure of one of the caches. A cache fail means that other > caches will do a direct, instead of using a second-in-line cache. > That means the site will probably get the same request about > (nr of caches) times instead of a single time. > For some sites that is a real no-go.
Which is why I mentioned the CARP algorithm as it already deals with this.. if one member of the farm dies the content for which this member was denoted master will be redistributed evenly (according to assigned weights) among the other caches.. In a properly functioning CARP array each member keeps a table of the members in the array and their availability. If for the requested URL this cache is not the highest ranking server which is beleived to be alive the request should be reforwarded to the highest ranked alive server. For each given URL all the caches are actually candidates, only their ranking differ. The role of CARP in accelerator setups is mainly to channelize the refreshes, as accelerators usually have to deal with relative small amounts of content and can afford all caches to cache all, because of this the loss in hitratio from loosing one cache is minimal (approaches 0%). The role of CARP in an farm of forward proxies may be do distribute the caching role among the caches to allow for a bigger cache than a single server can handle, or to simply channellize the refreshes as the accelerator setup.. But seriously speaking I think your main problem is to make Squid collapse the refreshes of the same object. If the collapses are done you get at worst N concurrent refreshes for the same object, not as many refreshes as there is clients requesting that object when it went stale... this change alone should do a very big difference. If this is not sufficient CARP can be used but for this to be noticeable you need to have a farm of very many accelerators (20 or more). As you consider ICP as useable this is not the case.. (20 or more servers speaking ICP to each other for a high request rate would leave very little time to actually process HTTP requests...) Regards Henrik
