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

Outline Introduction Classification –Recency-based –Frequency-based –Recency/frequency-based –Function-based –Randomized Discussions –Importance in nowadays –Future research topics Conclusions 2/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 network bandwidth usage Reducing user- perceived delays Reducing loads on the origin server Increasing robustness of web services Providing a chance to analyze an organizations 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 Conclusions 7/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 extension of it 10/35

Recency-based schemes LRU –Remove the least recently used object LRU-Threshold –Dont 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: 2 i-1 ~ 2 i -1 –Each class has a separate LRU list –Whenever there is a replacement Choose largest among the least recently used objects of each class – : Size of the object – : The number of accesses since the last request 12/35

Characteristics Pros –Suited when web request streams exhibit temporal locality –Simple to implement and fast Cons –In general, size is not combined with recency 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 extension 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 K i -value object is replaced –The value of this object is assigned to L 16/35

Characteristics Pros –Valuable in static environments Popularity does not change over a time period Cons –Complex to implement –Cache pollution Old, popular objects dont be removed Overcome with aging 17/35

Recency/frequency-based strategy Use recency and LRU* –If least recently used objects counter is zero, replace it –Otherwise, decrease its counter and move it to the beginning of list(Most recently 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 – c s : time to contact server, b s : bandwidth to server, W b &W n : parameters 20/35

Characteristics Pros –Can control weighting parameters Optimization is possible –Consider many factors Can handle different workload situations Cons –Choosing appropriate parameters is difficult –Using latency as a factor is danger Latency changes depending upon time 21/35

Randomized strategy Use randomized decisions RAND –Remove a random object HARMONIC –Give probability inversely proportional to cost, c i /s i (c i : cost to fetch, s i : size of object) 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 Conclusions 24/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 objects [1] Basic LRU is sufficient But, cacheable object will grow in future –Multimedia files [1]. Web caching and replication, Rabinovich and Spatscheck [2002] 26/35

Reduction of cacheable traffic 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 evaluations –PSS, etc Some function-based strategies with weighting parameters can be optimized 28/35

Alternative models Static caching –Content of the cache is updated periodically –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) depending on actual workload –Strong temporal locality workload LRU –Workload with no request fluctuations LFU Problems –Need smooth change of strategies –Wrong changes make performance worse 31/35

Coordinated replacement Make decision with considering other caches status –Cooperative caching There are some papers of cooperative 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, /35

Multimedia cache replacement 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 strategies 35/35

APPENDIX 36

Large cache A caches 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 sets mMaximum stack distance: 15 millions 37/35