A Hybrid Caching Strategyfor Streaming Media Files
Jussara M.Almeia, Derek L.Eager, Mary K. VernonDepartment of Computer Science,
University of Wisconsin-Madison, USAUniversity of Saskatchewan, Canana
2006.3.23SNU, OSLAB
Speaker : Kim Jungkuk
SNU, OSLAB
Table of Contents
Introduction Background
Current Caching Policies Caching Policy Comparison Improving Current Policy
Pooled RBC LFU/IC Experimental Results
Conclusion Future Work
SNU, OSLAB
Introduction
Evaluate several policies for caching streaming media files at proxy servers LFU, RBC, Interval Caching, etc.
Compare LFU to RBC Pooled RBC improved in 4 parts, compared to RBC
Suggest a new hybrid LFU/IC policy (maybe best for VOD-like workloads) much simpler to implement than (Pooled) RBC performs better than ordinary LFU not compared with LRU yet
SNU, OSLAB
Introduction
Characteristics of Streaming media files video files are big
most of cached content needs to be stored on disks both disk cache & main memory buffering need to be
managed well real time media file transfer require a significant
amount of disk & network i/o bandwidth for a long time. effective caching algorithm needed not to interfere current streaming services disk bandwidth utilization is important to save new
contents partial file caching is also important (for various client workloads, e.g., VOD searching)
SNU, OSLAB
Introduction
Parallel work considers a proxy cache distributed among N servers in which each
video is partitioned into N blocks for load balancing purpose
use a set of client request traces
to compare several hierarchical
file/block-level caching policies, including LFU, FIFO, LRU-k
SNU, OSLAB
LFU caching policy
simply caches the (partial) files to have highest access frequency
key open questions data granularity
using the granularity of the data request issued by clients. measuring separately layer by layer
current access freq. estimation (at actual system) ref. counts with an aging mechanism ref. counts by weighting the fraction of the file accessed the mean time b/w requests
overall consumption each policy knows access frequency perfectly
SNU, OSLAB
Interval Caching Policy
caching partial video streams in main memory Interval : deleted when the second client
receives it Run : deleted when a later client
receives it
SNU, OSLAB
RBC (Resource Based Caching) utilizing the limited resource, either disk
space and disk bandwidth characterizes each file object by
its space and bandwidth requirement caching gain measure (read client request * bit rate)
intuitive goal to maximize the disk bandwidth leads to optimal policy performance (that is, estimation accuracy & system not
bandwidth-constrained) caches a mixture of intervals & full files
SNU, OSLAB
RBC (Resource Based Caching) Caching Procedure
Step1 : using Table 2a to select the granularity of file (interval, run, full file)
Step2 : using table 3 to decides if the entity selected in step 1 should be cached
manages 2 ranked list of cached entities Space goodness list Bandwidth goodness list to keep bandwidth & space utilization equal using step1
when choosing the granularity of the entity to cache cf.)to use step1 (Table2.b) in Pooled RBC (choose entity max.
Gspace)
SNU, OSLAB
RBC (Resource Based Caching) Parameters used in RBC (Tbl. 1)
SNU, OSLAB
RBC (Resource Based Caching)
RBC Step 1 (Tbl. 2) Select granularity of entity
a) original RBC
b) proposed simplified step 1
RBC Step 2 (Tbl. 3) Caching Decision for entity
SNU, OSLAB
Caching Policy Comparison
Primary metric byte hit ratio
the fraction of the total bytes delivered that are delivered from the cache (cf.) hit ratio
System Assumptions The proxy server has sufficient network i/o
bandwidth for streaming data from its memory and disk
SNU, OSLAB
Caching Policy Comparison
System Assumptions a fixed number of files, n, each access is independent fixed access frequencies skewed as defined by a Zipf-like dist
ribution with parameter θ (i.e., Pi=P(access file i) =C/i(1- θ)) (for videos & web content) all files have the same size & same delivery rate (r) each client requests the entire file, thus the delivery time T is
same for all. client request arrivals are Poisson, with request rate λ (web pr
oxy) files are placed on several disks for load balancing
SNU, OSLAB
Caching Policy Comparison
System workload Parameters Cache size ( C )
a fraction of the total file data. captures T & r (uniform file duration T, uniform file streaming rate r) ranges from 0 to 1
total client request arrival rate (N) average # of client requests that arrive during the avg. time it
takes to stream a file to a single client. related to total bandwidth (sufficient b/w for deliver all
request?) normally 100 to a few thousands
total disk bandwidth (B) r * S^ , where S^ is the average # of active streams that are
needed to deliver the data that is cached by the LFU policy.
SNU, OSLAB
Caching Policy Comparison perf. comparison of RBC & LFU (n=100)
insensitive to arrival rate N sensitive to B & C LFU > RBC only on red circle
SNU, OSLAB
Caching Policy Comparison
Impact of system parameters
insensitive to number of files, n (C=10%, N=40)
SNU, OSLAB
Caching Policy Comparison Avg. fraction of each file cached by RBC (N=450, n=100, C=0.25)
RBC doesn’t allow unused b/w that is currently allocated to one file to be used to serve a request to another file
RBC only caches a file if there is enough unallocated disk b/w so, RBC caches fewer files than LFU.
SNU, OSLAB
Caching Policy Comparison
Space & Bandwidth Utilization
SNU, OSLAB
Improving RBC and LFU
Pooled RBC bandwidth pool
enables full files to share bandwidth allocation whenever a new full file is added to the cache, its b/w allocation is added to the b/w pool when request, new stream from b/w pool is assigned. when finished, b/w is returned to the pool. uses Tbl.2.b simplified step 1. to select granularity. if no more steam from b/w pool, forward req. to
remote server rather trying to evict entity. allow intervals to remain in cache when file is
evicted.
SNU, OSLAB
Improving RBC and LFU
Perf. of pooled RBC & LFU (N=450,n=100)
SNU, OSLAB
Improving RBC and LFU
Hybrid LFU/IC Disk Caching improve perf. by storing intervals in a small, separat
e cache, either in main memory or in a small fraction of the available disk space
LFU/ICmem, Pooled RBC/ICmem better perf. than ordinary LFU & Pooled RBC
LFU/ICdisk if a file becomes suddenly very popular, interval caching ca
n be used to serve some requests from the proxy while enough info. becomes available
to decide to cache the entire file in the LFU disk cache
SNU, OSLAB
Improving RBC and LFU
Perf. of Hybrid RBC&LFU w/ ICmem (M=0.25%)
SNU, OSLAB
Improving RBC and LFU
Perf. of Hybrid LFU/ICdisk (s=5%)
if s=10%, hurts performance for cache size C > 0.8
SNU, OSLAB
Conclusions
RBC > LFU if excess disk bandwidth and cache size is small. In other cases, LFU > RBC.
Pooled RBC has 4 improvements to RBC. sharing of allocated bandwidth among the cached files improvement in bandwidth deficient and balanced
system. but, (Pooled) RBC share a complex implementation
and high time complexity Hybrid LFU/IC policy shows better performance
with Interval caching done in a separate small cache, either in main memory or on disk
SNU, OSLAB
Future Work
Evaluating caching policies using workload traces from client request logs for various VOD servers.
Workload trace include an unknown and dynamically changing set of file access frequency
Practical method of estimating file access freq.
Comparing LFU/IC to LRU-k policy
Top Related