[squid-users] Ideal cache placement (was Re: Why Squid is great (was: fourth cache off??))

Jon Kay wrote:
>
> I think this is a good time to suggest a new doctrine on caching and
> cache placement. The way to get the most out of a cache is not to buy
> a really big one and centralize it, but get a bunch of small ones and
> put them topologically close to users.

I think this is a potentially dangerous argument to make without
any supporting evidence. To demonstrate why, let's push this to
its natural conclusion, where each users has his/her own private
cache. In this scenario, it's hard to see how the caches are of
much benefit, because of the lack of sharing. Adding new communications
into the mix may not be a clear win, especially if the extra
communication doesn't scale well with the number of caches.

> The main point of a cache is not to serve lots of requests, but rather
> to improve the network experience for a certain user population.
> Specifically, it reduces latency. Yes, it also saves on bandwidth,
> but the reason people care about that bandwidth savings is that users
> would have to wait longer if it were used by many requests for popular
> content.
>
> Now, the way a cache works best is if it is "near" its user
> population. A server delivers content more and more slowly not only

Our experience, and the experience of others, seems to indicate that
a cache's hit rate generally increases as the client population
increases. This concept is the reason why you'd expect any bandwidth
savings from hierarchical caches. The drawback to hierarchical caches
is the additional latency involved in the hierarchy - much worse
than router hops or line losses. There's a reasonably good paper
that puts things in perspective:
http://www.cs.washington.edu/research/networking/websys/pubs/sosp99/

My gut feeling is that caches near real choke points make sense,
and that caches near similar user populations also potentially
makes sense. As for ideal placement, that probably depends more
on topology than any blanket assertion can easily cover.

-Vivek

P.S. Usual disclaimer applies, although here it's probably a non-issue
Received on Thu Dec 20 2001 - 07:19:58 MST