1 Simulation Evaluation of a Heterogeneous Web Proxy Caching Hierarchy Mudashiru Busari Carey Williamson University of Saskatchewan University of Calgary MASCOTS 2001

2 Introduction z“The Web is both a blessing and a curse…” zBlessing: yInternet available to the masses ySeamless exchange of information zCurse: yInternet available to the masses yStress on networks, protocols, servers, users zMotivation: improve the performance and scalability of the Web (e.g., caching)

3 Example of a Web Proxy Cache Proxy server Web server Web Client

4 Our Previous Work zEvaluation of Canada’s national Web caching infrastructure for CANARIE’s CA*net II backbone zWorkload characterization and evaluation of CA*net II Web caching hierarchy (IEEE Network, May/June 2000) zDeveloped Web proxy caching simulator for trace-driven simulation evaluation of Web proxy caching architectures zDeveloped synthetic Web proxy workload generator called ProWGen [Busari/Williamson INFOCOMM 2001]

CA*net II Web Caching Hierarchy (Dec 1998) USask CANARIE (Ottawa) (selected measurement points for our traffic analyses; 6-9 months of data from each) To NLANR

Caching Hierarchy Overview C C CCCCC Proxy... Regional/Univ. (5-10 GB) National (10-20 GB) Top-Level/International (20-50 GB) Cache Hit Ratios 30-40% 15-20% 5-10% (empirically observed)

7 Some Observations on Multi-Level Caching... zCaching hierarchy not very effective zReason: workload characteristics change as you move up the caching hierarchy (due to filtering effects, etc) zIdea #1: Try different cache replacement policies at different levels of hierarchy zIdea #2: Limit replication of cache content in overall hierarchy through “partitioning” (size, type, sharing,…)

8 Research Questions: Multi-Level Caches zIn a multi-level caching hierarchy, can overall caching performance be improved by using different cache replacement policies at different levels of the hierarchy? zIn a multi-level caching hierarchy, can overall performance be improved by keeping disjoint document sets at each level of the hierarchy?

9 Experimental Methodology zTrace-driven simulation zMulti-factor experimental design zCache size y1 MB to 32 GB zCache Replacement Policy yLeast-Recently-Used (currently active docs) yLeast-Frequently-Used (popular docs) yGreedy-Dual-Size (favours smaller docs) zWorkload Characteristics yDegree of overlap amongst child caches

10 Simulation Model Proxy server Web Servers Web Clients Proxy server Upper Level (Parent) Complete Overlap No Overlap Partial Overlap (50%) Lower Level (Children)

11 Web Proxy Workload Used zSynthetically generated workload using ProWGen proxy workload generator [Busari/Williamson INFOCOMM 2001] zParameterized based on empirical data zZipf-like document popularity profile zLots of “one-timer” documents zHeavy-tailed file size distribution zNote: static content only

12 Parameter Value Total number of requests Unique documents (of total requests) One-timers (of unique documents) Zipf slope Tail Index Documents in the tail Beginning of the tail (bytes) Mean of the lognormal file size distribution Standard deviation Correlation between file size and popularity LRU Stack Model for temporal locality LRU Stack Size 5,000,000 34% 72% % 10,000 7,000 11,000 Zero Static and Dynamic 1,000 Workload Characteristics

13 Zipf-like Referencing Behaviour Empirical Trace Slope = 0.81 Synthetic Trace Slope = 0.83

14 Performance Metrics zDocument Hit Ratio yPercent of requested docs found in cache (HR) zByte Hit Ratio yPercent of requested bytes found in cache (BHR) Notes: - application-level simulation (files), not network-level (pkts) - all three caches always identical in size

15 Experiment 1: Different Policies at Different Levels of the Hierarchy (Complete Overlap) (a) Hit Ratio (b) Byte Hit Ratio Parent Children

16 Parent Children

17 Experiment 2: Sensitivity to Workload Overlap zThe greater the degree of workload overlap amongst the child proxies, the greater the role for the parent cache zIn the “no overlap” scenario, the parent cache has negligible hit ratios, particularly when child caches are large

18 Experiment 3: Size-based Partitioning zPartition files across the two levels of the hierarchy based on size (e.g., keep small files at the lower level and large files at the upper level) (or vice versa) zThree size thresholds for “small”... y5,000 bytes y10,000 bytes y100,000 bytes

19 Size threshold = 5,000 bytes Size threshold = 10,000 bytes Small files at the lower level; Large files at the upper level Parent Children

20 Size threshold = 5,000 bytes Size threshold = 10,000 bytes Children Parent Large files at the lower level; Small files at the upper level

21 Summary: Multi-Level Caches zDifferent Policies at different levels yLRU/LFU-Aging at the lower level + GD-Size at the upper level provided improvement in performance yGD-Size + GD-Size provided better performance in hit ratio, but with some penalty in byte hit ratio zSize-threshold approach ysmall files at the lower level + large files at the upper level provided improvement in performance yreversing this policy offered no perf advantage

22 Conclusions zProWGen is a valuable tool for the evaluation of Web proxy caching architectures, using synthetic workloads zExisting multi-level caching hierarchies are not always that effective z“Heterogeneous” caching architectures may better exploit workload characteristics and improve Web caching performance

23 Future Work zExtend and improve ProWGen zUse of packet-level simulations to understand protocol/network-level effects zPort ProWGen to network emulation testbed at the U of Calgary

24 For More Information... zM. Busari, “Simulation Evaluation of Web Caching Hierarchies”, M.Sc. Thesis, Dept of Computer Science, U. Saskatchewan, June 2000 zProWGen tool: yhttp:// z yhttp://