Re: Cache replacement policy still make sense?

On Wednesday 27 August 2003 04.14, K. Y. Wong wrote:
> Hello,
>
> Considering today's large disk size (>120G), does a cache
> replacement policy still play a important role in the cache
> performance?

Marginally.

> Although a large cache will be eventually filled up with files,
> many of the cached files will be expired before the cache is full.
> Therefore, simply removing that expired files will make a
> considerable space for many future requests, and it does not matter
> that which replacement policy (LRU, LFUDA, or GDS) is used. Right?

Right.. all policies will remove very old objects when the cache is
very large. There is no noticeable difference if the very oldest
objects or the almost oldest objects are deleted.

> On the other hand, from the benchmarking results shown in:
> http://www.squid-cache.org/Benchmarking/HEAP_REPLACEMENT/index.html
> We can see that LRU, LFUDA, and GDS perform similarly. It further
> support the argument that a replacement policy is playing a LESS
> important role in the Web performance. Am I correct?

It is a well studied fact that all age related policies approximate
the same results for larger caches. The less frequently the object is
accessed the less likely it is it will be accessed again.

See the HP research paper for some results, but there is several other
research papers with this conclusion.

> But, in the above benchmarking result, I do not understand:
> 1) the "Millions of requests" in the x axis mean. It is the number
> of requests per second? or is the accumulated number of requests?

In the "Throughput" graph the X-axis represents the number of requests
since start and the Y-axis represents the requests per second. The
workload uses "number or requests since start" as it's time scale,
not real time.

> 2) the hit ratios are similar until 4 millions of requests is
> reached. Does it mean, at that arrival rate, the cache is full, and
> the correct choose of a replacement policy will take effect at that
> case?

Probably. I am not very familiar with this old polygraph workload, but
it does not seem to have a fill phase like the current workloads.

The Datacomm-1 workload which is the basis of this workload is not
really interesting for gaining a understanding of real-life
behaviour, only for making comparisations on changes. You should not
attempt to read anything from such tests other than how two different
setups relates to each other.

Regards
Henrik
Received on Wed Aug 27 2003 - 02:48:38 MDT