A Survey of Web Cache Replacement Strategies Stefan Podlipnig, Laszlo Boszormenyl University Klagenfurt ACM Computing Surveys, December 2003 Presenter:

A Survey of Web Cache Replacement Strategies

Stefan Podlipnig, Laszlo BoszormenylUniversity Klagenfurt

ACM Computing Surveys, December 2003

Presenter: Junghwan Song2012.04.25

Outline

• Introduction• Classification

– Recency-based– Frequency-based– Recency/frequency-based– Function-based– Randomized

• Discussions– Importance in nowadays– Future research topics

• Conclusions2/35

Why was caching born?

• Web has been growing– Load on the Internet and web servers

increase

Caching have been introduced

3/35

Caching effect

• Reducing networkbandwidth usage

• Reducing user-perceived delays

• Reducing loads on the origin server• Increasing robustness of web services• Providing a chance to analyze an or-

ganization’s usage pattern

4/35

When cache becomes full..

• To insert new objects, old objects must be removed–Which objects do we select?

Cache replacement strategy

5/35

General cache operation

• Cache miss Cache stores new object

• Cache hit Cache serves requested objects

• Cache full Cache evicts old objects

6/35

Outline

• Introduction• Classification

– Recency-based– Frequency-based– Recency/frequency-based– Function-based– Randomized

• Discussions– Importance in nowadays– Future research topics

• Conclusions7/35

Classification factors

• Important factors for classification– Recency

• Time of since the last reference

– Frequency• The number of requests

– Size–Modification

• Time of since last modification

– Expiration time• Time when an object gets stale

8/35

Classification

• Recency-based strategy• Frequency-based strategy• Recency/frequency-based strategy• Function-based strategy• Randomized strategy

9/35

Recency-based strategy

• Recency is a main factor• Based on the temporal locality– Temporal locality: Burst accesses in

short time period

• There are well-known LRU and exten-sion of it

10/35

Recency-based schemes

• LRU– Remove the least recently used object

• LRU-Threshold– Don’t cache when size of new object is

exceeds the threshold

• SIZE– Remove the biggest one– LRU is used as a tie breaker

11/35

Recency-based schemes

• PSS– Classify objects depending upon their

size• Range: 2i-1 ~ 2i-1

– Each class has a separate LRU list–Whenever there is a replacement• Choose largest among the least re-

cently used objects of each class– : Size of the object– : The number of accesses since the last re-

quest

ii Ts

isiT

12/35

Characteristics

• Pros– Suited when web request streams ex-

hibit temporal locality– Simple to implement and fast

• Cons– In general, size is not combined with re-

cency well• Except PSS

13/35

Frequency-based strategy

• Use frequency as a main factor• Based on popularity of web objects– Frequency represents popularity

• There are well-known LFU and exten-sion of it

14/35

Two forms of LFU

• Perfect LFU– Count all requests to an object i• Request counts persist across replacement

– Represent all requests from the past– Space overhead

• In-cache LFU (We assume this)– Count requests to cached objects only– Cannot represent all requests in the past– Less space overhead

15/35

Frequency-based schemes

• LFU– Remove the least frequently used object

• LFU-Aging– If avg(all frequency) exceeds certain threshold,

all frequency counter/2

• LFU-DA– Each request for object i, calculate following

• L is an aging factor, initialized to zero• Smallest Ki-value object is replaced

– The value of this object is assigned to L

LfK ii

16/35

Characteristics

• Pros– Valuable in static environments• Popularity does not change over a time pe-

riod

• Cons– Complex to implement– Cache pollution• Old, popular objects don’t be removed• Overcome with aging

17/35

Recency/frequency-based strategy

• Use recency and frequency(+@)• LRU*– If least recently used object’s counter is

zero, replace it– Otherwise, decrease its counter and

move it to the beginning of list(Most re-cently used position)

18/35

Characteristics

• Pros– Can take advantages of both recency

and frequency

• Cons– Additional complexity is added– Simple scheme(ex. LRU*) neglects size

19/35

Function-based strategy

• Use a potentially general function• GD-Size– , where L is a running aging factor– Smallest-value object is selected

• HYBRID

–

• cs: time to contact server, bs: bandwidth to server, Wb&Wn: parameters

Ls

cH

i

ii

i

nis

bs

s

WfbW

cif

)()(

20/35

Characteristics

• Pros– Can control weighting parameters

• Optimization is possible

– Consider many factors• Can handle different workload situations

• Cons– Choosing appropriate parameters is diffi-

cult– Using latency as a factor is danger

• Latency changes depending upon time21/35

Randomized strategy

• Use randomized decisions• RAND– Remove a random object

• HARMONIC– Give probability inversely proportional to

cost, ci/si (ci: cost to fetch, si: size of ob-ject)

22/35

Characteristics

• Pros– Simple to implement

• Cons– Hard to evaluate• Results of simulations that is run on the

same Web server are slightly different

23/35

Outline

• Introduction• Classification

– Recency-based– Frequency-based– Recency/frequency-based– Function-based– Randomized

• Discussions– Importance in nowadays– Future research topics

• Conclusions24/35

Importance in nowadays

• Questions on importance of cache replacement strategies– Large cache– Reduction of cacheable traffic– Good-enough algorithms– Alternative models

25/35

Large cache

• The capacity of caches grows steadily– Replacement strategies are not seen as

a limiting factor–Working set for clients<<Cached ob-

jects[1]

• Basic LRU is sufficient

• But, cacheable object will grow in fu-ture–Multimedia files

[1]. Web caching and replication, Rabinovich and Spatscheck [2002] 26/35

Reduction of cacheable traf-fic

• Non-cacheable data is of a significant percentage of the total data– Around 40% of all requests

• Overcome with active cache, server accelerator– Active cache: Let proxy cache applets– Server accelerator: Provide an API which

control cached data explicitly

27/35

Good-enough algorithms

• There are already many algorithms that are considered as good enough– Give good results in different evalua-

tions– PSS, etc

• Some function-based strategies with weighting parameters can be opti-mized

28/35

Alternative models

• Static caching– Content of the cache is updated periodi-

cally– Popularity of objects is determined in

prior period

• Give TTL to cached objects– Simple to implement– Large TTL causes large cache storage

usage

29/35

Future research topics

• Adaptive replacement• Coordinated replacement• Replacement + coherence• Multimedia cache replacement• Differentiated cache replacement

30/35

Adaptive replacement

• Change replacement strategies(or parameters in function-based) de-pending on actual workload– Strong temporal locality workload LRU–Workload with no request fluctuations

LFU

• Problems– Need smooth change of strategies–Wrong changes make performance

worse31/35

Coordinated replacement

• Make decision with considering other caches’ status– Cooperative caching

• There are some papers of coopera-tive caching in ICN–WAVE(2012)[2]

– Age-based cooperative caching(2012)[3]

[2] WAVE: Popularity-based and Collaborative In-network Caching for Content-Oriented Networks,K Cho et al, 2012

[3] Age-based Cooperative Caching in Information-Centric Networks, Z ming et al, 2012 32/35

Multimedia cache replace-ment

• Multimedia caching research will be dominated by video– Videos are the biggest objects– How to cache this big file• Chunks, partial caching, quality-adjust, etc

33/35

Differentiated cache replacement

• Support QoS in caching– Ex) Classify caches into different classes

• Two kinds of differentiation– Using information given by servers– Handled by only proxy• Add some overhead• How to simplify?

34/35

Conclusions

• Give an exhaustive survey of various cache replacement strategies

• Show that there are future research areas of cache replacement strate-gies

35/35

36

APPENDIX

Large cache

• A cache’s handleable rate: 1000 req/sec• Average size of objects: 10KB• Request rate of above: 82Mbps• 60% are cacheable, 40% hit rate:

16.4Mbps (2.05 MBps)• Disk capacity 200 GB: 21 millions objects• Working set’s mMaximum stack dis-

tance: 15 millions

37/35