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

1

Simulation Evaluationof a HeterogeneousWeb Proxy Caching Hierarchy

Mudashiru Busari Carey WilliamsonUniversity of Saskatchewan University of Calgary

MASCOTS 2001

2

Introduction

“The Web is both a blessing and a curse…”

Blessing: Internet available to the masses Seamless exchange of information

Curse: Internet available to the masses Stress on networks, protocols, servers, users

Motivation: improve the performance and scalability of the Web (e.g., caching)

3

Example of a Web Proxy Cache

Proxy server

Web server

Web server

Web server

Web Client

Web Client

Web Client

Web Client

Web Client

4

Our Previous WorkEvaluation of Canada’s national Web caching

infrastructure for CANARIE’s CA*net II backboneWorkload characterization and evaluation of

CA*net II Web caching hierarchy (IEEE Network, May/June 2000)

Developed Web proxy caching simulator for trace-driven simulation evaluation of Web proxy caching architectures

Developed synthetic Web proxy workload generator called ProWGen [Busari/Williamson INFOCOMM 2001]

CA*net II Web Caching Hierarchy (Dec 1998)

USask

CANARIE(Ottawa)

(selectedmeasurement points for our traffic analyses; 6-9 months of data from each)

To NLANR

Caching Hierarchy Overview

C C C CC C C

Proxy

Proxy

Proxy Proxy

Proxy

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%(empiricallyobserved)

7

Some Observationson Multi-Level Caching...

Caching hierarchy not very effectiveReason: workload characteristics change

as you move up the caching hierarchy (due to filtering effects, etc)

Idea #1: Try different cache replacement policies at different levels of hierarchy

Idea #2: Limit replication of cache content in overall hierarchy through “partitioning” (size, type, sharing,…)

8

Research Questions:Multi-Level Caches

In a multi-level caching hierarchy, can overall caching performance be improved by using different cache replacement policies at different levels of the hierarchy?

In a multi-level caching hierarchy, can overall performance be improved by keeping disjoint document sets at each level of the hierarchy?

9

Experimental MethodologyTrace-driven simulationMulti-factor experimental designCache size

1 MB to 32 GBCache Replacement Policy

Least-Recently-Used (currently active docs)

Least-Frequently-Used (popular docs) Greedy-Dual-Size (favours smaller docs)

Workload Characteristics Degree of overlap amongst child caches

10

Simulation Model

Proxy server

Web Servers

Web Clients

Proxy server

Proxy server

Upper Level (Parent)

Complete Overlap

No Overlap

Partial Overlap (50%) Lower Level

(Children)

11

Web Proxy Workload Used

Synthetically generated workload using ProWGen proxy workload generator [Busari/Williamson INFOCOMM 2001]

Parameterized based on empirical dataZipf-like document popularity profileLots of “one-timer” documentsHeavy-tailed file size distributionNote: static content only

12

Parameter Value

Total number of requestsUnique documents (of total requests)One-timers (of unique documents)Zipf slopeTail IndexDocuments in the tail Beginning of the tail (bytes)Mean of the lognormal file size distributionStandard deviation Correlation between file size and popularityLRU Stack Model for temporal localityLRU Stack Size

5,000,00034%72%0.8071.32222%10,0007,00011,000ZeroStatic and Dynamic1,000

Workload Characteristics

13

Zipf-like Referencing Behaviour

Empirical Trace Slope = 0.81

Synthetic Trace Slope = 0.83

14

Performance Metrics

Document Hit Ratio Percent of requested docs found in

cache (HR)Byte Hit Ratio

Percent of requested bytes found in cache (BHR)

Notes: - application-level simulation (files), not network-level (pkts) - all three caches always identical in size

15

010203040506070

1 100 10000Cache Size (MB)

Byte

Hit

Ratio

Children (LRU) Parent (GD-Size)

Parent (LFU-Aging) Parent (LRU)

01020304050607080


Hit R

atio



Experiment 1: Different Policies at Different Levels of the Hierarchy (Complete Overlap)

(a) Hit Ratio (b) Byte Hit Ratio

Parent Parent

Children

Children

16

01020304050607080


Hit

Rat

ioChildren (LRU) Parent (GD-Size)


Parent

Children

17

Experiment 2:Sensitivity to Workload Overlap

The greater the degree of workload overlap amongst the child proxies, the greater the role for the parent cache

In the “no overlap” scenario, the parent cache has negligible hit ratios, particularly when child caches are large

18

Experiment 3:Size-based Partitioning

Partition 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)

Three size thresholds for “small”... 5,000 bytes 10,000 bytes 100,000 bytes

19

010203040506070


Hit

Ra

tio


Parent (LRU) Parent (LFU-Aging)

010203040506070


Byt

e H

it R

ati

o


Parent (GD-Size) Children (LRU)

Size threshold = 5,000 bytes

010203040506070


Hit

Ra

tio



010203040506070


Byt

e H

it R

ati

o




Small files at the lower level; Large files at the upper level

Parent

Children

20Size threshold = 5,000 bytes

010

2030

4050

6070


Hit

Ra

tio

Parent (GD-Size) Parent (LRU)

Parent (LFU-Aging) Children (LRU)

010203040506070


Byt

e H

it R

ati

o

Children (LRU) Parent (LRU)

Parent (LFU-Aging) Parent (GD-Size)


0

1020

3040

5060

70


Hit

Ra

tio

Parent (GD-Size) Parent (LRU)

Parent (LFU-Aging) Children (LRU)

010203040506070


Byt

e H

it R

ati

o



ChildrenParent

Large files at the lower level; Small files at the upper level

21

Summary: Multi-Level CachesDifferent Policies at different levels

LRU/LFU-Aging at the lower level + GD-Size at the upper level provided improvement in performance

GD-Size + GD-Size provided better performance in hit ratio, but with some penalty in byte hit ratio

Size-threshold approach small files at the lower level + large files at the

upper level provided improvement in performance reversing this policy offered no perf advantage

22

Conclusions

ProWGen is a valuable tool for the evaluation of Web proxy caching architectures, using synthetic workloads

Existing multi-level caching hierarchies are not always that effective

“Heterogeneous” caching architectures may better exploit workload characteristics and improve Web caching performance

23

Future Work

Extend and improve ProWGenUse of packet-level simulations to

understand protocol/network-level effects

Port ProWGen to network emulation testbed at the U of Calgary

24

For More Information...

M. Busari, “Simulation Evaluation of Web Caching Hierarchies”, M.Sc. Thesis, Dept of Computer Science, U. Saskatchewan, June 2000

ProWGen tool: http://www.cs.usask.ca/faculty/carey/software/

Email: [email protected] http://www.cpsc.ucalgary.ca/~carey/