Adaptive Configuration of a Web Caching Hierarchy Pranav A. Desai Jaspal Subhlok Presented by: Pranav A. Desai

Introduction  Web caching  Used to improve the performance of the World Wide Web  Hierarchy of caches  Further enhances the performance  Goal of the research  Improve the performance of a caching hierarchy

Outline  Web caching hierarchy  Motivation  Approach  Adaptive Hierarchy Management System  Performance evaluation  Conclusion & Future work

Web Caching Hierarchy  A network of cooperating caches hierarchically arranged in a tree-like structure  Caches can have sibling-sibling or parent- child relationship with other caches

Web Caching Hierarchy Child Web Caches Parent Web Cache parent-child relationship sibling-sibling relationship ICP Queries Request to Origin Server

Motivation  Limitations of a caching hierarchy  Requires manual configuration  Changes in network conditions may deteriorate the performance of the caches in the hierarchy

Cache A Cache BCache C Example All sibling hierarchy Request Congested network to Origin Server

Cache A Cache BCache C Example All sibling hierarchy

Metrics we need to consider  Available bandwidth (network metric)  Indicative of the overhead associated with cooperating with peer caches  Inter-cache hit ratio (cache metric)  Measures the benefit due to hierarchy  Other metrics that we considered  Request hit ratio  Request rate  CPU load  Service time (hits and misses)  Round trip time

Solution  Requires two components  A mechanism  Collect the metrics  Reconfigure the caches  A policy  An algorithm that can design a hierarchy using the metrics

Cache A Cache BCache C CONTROLLER NW S AGENTS Adaptive Hierarchy Management System

Adaptive Hierarchy Algorithm  The algorithm uses threshold values for the metrics to design the hierarchy  The threshold values are determined empirically

Experimental Setup  Experiments are performed on a Squid cache hierarchy of three sibling caches  Bandwidth is controlled using Dummynet  Client robots send requests from web traces obtained from NLANR (National Laboratory for Applied Network Research)  Traces are randomly selected from different sites in the NLANR hierarchy

Determination of threshold values   Traces used are requests long   Bandwidth is varied in step of 100, 10, 1, 0.1 Mbps   To simulate realistic conditions the caches are warmed before performing the experiments   Sending specific amount of requests to the caches before performing the experiments   Three levels of warming – 0%, 50%, 100%   Threshold values are determined by comparing the performance of the hierarchies A CB Hierarchy 0 A CB Hierarchy 1

Impact of Sibling Cache   Benefit of hierarchy is not obtained due to high ICP overhead and low inter-cache hit ratio A CB Hierarchy 0 A CB Hierarchy 1

Impact of Sibling Cache A B Hierarchy 0 A C B Hierarchy 1 C

Adaptive Hierarchy Algorithm  For bandwidths > 10Mbps cooperating with peer caches is beneficial  For bandwidths in the range 10 – 1 Mbps communicating with peer cache is beneficial if inter-cache hit ratio > 6%  For bandwidth < 1Mbps eliminating the relationship is beneficial in all cases

Adaptive Hierarchy Algorithm Select a Link BW < 1% of maxBW ? Set Link Relation to NONE 1% < BW < 10% of maxBW ? IC_HR < 6% ? Set Relation to SIBLING Check Link Relation Y Y Y N N NNONE PARENT or SIBLING

Performance of Adaptive Hierarchy  Bandwidth is varied randomly in steps of 100, 10, 1 and 0.1 Mbps  The period for each bandwidth phase is controlled  Each trace is about half million requests long A CB SiblingSibling Sibling

MeanMedian Performance with Adaptive Hierarchy   Performance improvement of 13% and 29% is obtained in mean response time for cache A and cache B respectively   Improvement is not evident from the median response time

Response time of individual requests

Conclusion  Adaptive Hierarchy Management System is capable of dynamically configuring a set of caches into good hierarchies  In our experimental setup Adaptive hierarchy performs better by around 30%

Future Work  Extensive evaluation of the system  Evaluation of other metrics  Request hit ratio  Request rate  Service time (Hit and Miss)  Round trip time  Auto discovery of caches

Thank You!