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
Top Related