Re: [squid-users] accelerator farm: optimizing the sibbling_hit

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
Received on Thu Mar 06 2003 - 16:00:08 MST