A Scalable Web Cache Consistency Architecture

2001/11/20 Internet Server 1

A Scalable Web Cache Consistency Architecture

Haobo Yu, Lee Breslau, Scott Shenker

SIGCOMM 99

Presentation : Cheolhyo Lee


Contents

Introduction Previous approach Main approach Analytical performance evaluation Simulation Additional design issue Conclusion Critiques


Introduction

Multicast-based invalidation Caching :

– Advantages lowers the load on servers reduces the overall network B.W. required lower the latency of responses

– Disadvantages inconsistent pages

Perishable pages - sensitive to being stale Goal : Ensure relative freshness => demonstrate that a

scalable web consistency architecture design is possible


Previous Approaches : Time-To-Live

A request arrives at a cache after the TTL for the requested page has expired => the cache send IMS(If-Modified-Since) message to the server

Small TTL <-> mitigates the benefits of web cache Poll-always : TTL=0 - generate IMS for every request longer unmodified, longer likely to be unmodified

=> Adaptive TTL :At the first request after each TTL expiration,TTL = K*(current time - last modification time)

Do not give an upper bound on the staleness of a page


Previous Approaches : Invalidation

Invalidation Scheme - Servers to send explicit invalidation signal to caches when pages are modified.

– Each servers keeps track of all clients who have requested a particular page -> when that page changes, notifies those client

– Servers have an invalidation contract with the clients: scaling problem arise

Multicast - Assigning multicast group to each page– somewhat related with the idea of pushing content– another burden at routers : order of addresses, the rate at which

clients would be joining and leaving

Another scheme - information including invalidation and delta-encoded page updates (for related pages )


Previous Approaches : Lease

Combine features of the TTL and invalidation– Whenever a cache stores a page, it requests a lease from the server– Whenever a page changes, the server notifies all caches who hold

a valid lease of the page : the invalidation contract applies only while the lease is valid

– If a cache receives a request for a page with an expired lease, it renews the page’s lease by sending an IMS to the server before responding to the request

– While lease is valid : invalidation schemeThe expiration of leases resembles the TTL approach.

Two volume lease algorithms – long lease : every page, short lease : to sets of pages volumes– reduce the validation traffic of short leases


Main approach

Proposed architecture=> Multicast-based invalidation + hierarchy of caches

– multicast groups are associated with caches– caches send heartbeats to each other– the unit of our lease is all pages in a cache– caches maintain a server table to locate where servers are attached

to the hierarchy– invalidation messages(sent up and down) for a page are filtered so

as to limit the scope of distribution– client requests are forwarded through the caching hierarchy to the

server or to the first cache containing a valid copy of requested page


Main approach (cont’d)

1) Simple description of protocol– all caches are infinite, all pages are part of this consistency arch.– There is single stable caching hierarchy with all caches having syn

chronized clocks, and no caches fail



Hierarchy– Fig.1

Heartbeats – each group owner sends out a periodic heartbeat message to its ass

ociated multicast group T/t– T/t : t - time period between heartbeats, T - volume lease of length– current time - the last heartbeat’s timestamp > T

: all pages from that server expires and all pages are marked as invalid



Invalidations– Read pages : invalidate pages that have been requested after they

were last rendered invalid=> each heartbeat message contains a list of all read pages at the present cache within the last time period T

– If a read page is rendered invalid at the parent cache at time t=0 th

en by time t=T, each child cache has either received a heartbeat with an invalidation for that page or has expired the lease from that parent cache

– child cache that had previously valid copy of page will mark it invalid and propagate iff the page was previously read



Attaching servers– Primary cache : each web server is attached to a cache– each server reliably unicast a JOIN message to its primary cache– upward to the tip-level cache -> the parent cache source a server fr

om a child cache– server routing table : each cache has a listing of those servers it so

urces -> Fig.2



Fig. 2



Attaching servers– top-level cache knows all servers attached– servers send (via unreliable unicast ) periodic heartbeats to their pr

imary cache, also piggybacking invalidations of any read pages– every child cache who sources at least one server must unicast hea

rtbeats to its parent with invalidations– each upstream cache is said to maintain an invalidation contract wi

th its immediate downstream cache for any page that has been read by a downstream cache

– LEAVE message : time period T has passed without cache C1 hearing from cache C2 from whom it sources a server - invalid



Handling requests– clients can attach to any cache : the client’s primary cache– when a client request a page, it sends the request to its primary

cache– the primary cache checks to see if the page is resident in the cache– if it is not -> the cache forwards the request to the next cache

designated by the server routing table– if the request is fulfilled -> the response takes the reverse path

through the caching hierarchy towards the clients



2. Discussion– Property 1 : If there are no invalidations in transit or waiting to

be sent, then if a cache C in the hierarchy has a page P marked as invalid, then no downstream cache considers P valid

– Property 2 : When a cache C receives an invalidation for a page P marked as invalid, it may safely discard the invalidation without affecting the resulting state of all downstream caches

– Property 3 : Assume that each cache uses the same timeout period T. Assume that there are H cache hops between server S1 and client C2. The maximum staleness of a page is HT

– Property 1 and 2 : reduce redundant invalidation traffic– Property 3 : set an upper bound of page staleness for every cache



3. Adding push to the architecture Pushing data : reduce first access latency Selective push : push only the delta’s from the previous ve

rsion of page– on the way up : via unreliable unicast– on the way down : use a single unreliable multicast sent to a cach

e’s multicast group

Selection for the push page– Ap : a counter for every cache(and the server)– push bit : for each of its push pages

if ‘1’ -> the cache will forward all pushed updates of the page to all of its downstream caches



– A cache receive an invalidation of page P -> Ap = Ap - a – A cache receive a request for page P -> Ap = Ap + b– If Ap > threshold -> push bit = 1, otherwise 0– let each downstream cache notify its immediate upstream cache w

hen a pushed page is first read and forwarded recursively until they hit a read page.

CMP(Continuous Multimedia Push)– assigns unique multicast group to every popular page and continuo

usly multicasts pages to their groups: when pages are popular and frequently change - good

LSAM– assigns one multicast group per topic


Analytical performance evaluation Assume

– Caches are infinite, behavior on a per-page basis– message generation behavior for a given page is indpendent of wh

at happens for all other pages– no delay between when invalidations are generated and their being

sent out

Omniscient TTL(OTTL)– caches know when a page has been modified and only send the IM

S request in those cases.

Poll-always(PA) - TTL=0 BINV - basic invalidation scheme with no page pushing PINV - invalidation scheme with pages always pushing


Analytical performance evaluation ( cont’d ) Patterns of read and writes arriving at a cache

– WR, RR, WW, RW ( depend on the order of read and write)

Table 1 : – hit rate : PINV < BINV, OTTL < PA– response time : PINV < BINV, OTTL < PA– B.W. is less clear

OTTL : less B.W. PA uses less B.W. than BINV iff 2r < w

– B.W. of control messages can be ignored -> server hit counts and response times are main performance criteria between BINV and PA

– PINV eliminates hit count and delays at the cost of increased B.W.


Analytical performance evaluation ( cont’d ) Table 1


Simulations

Simulator : ns simulator BINV, SINV, PINV, PA, ATTL, FTTL, OTTL User-centric metrics : client response time and

staleness(maximum and average staleness, stale hit rate) Infrastructure-centric metrics : total network B.W. ( in

byte-hops), the B.W. at the server, the rate of request(GET and IMS) at the server

Low average staleness is a performance requirement and how much B.W. and delay are incurred by the protocols to achieve a particular level of staleness


Simulations ( cont’d )

1) Two-level caching hierarchy– The workload in our basic scenario to have only single page– The performance of the consistency protocols on the reading and

writing patterns of a page– Write-dominated page : w/r = 10, read-dominated page : r/w = 5

Fig.3



RD case – Table 2 WD case – Table 3

– BINV’s performance advantage is reduced– SINV : like BINB in the WD case, like PINV in the RD case

Major benefits of invalidation scheme : saving of response time and server hit count

Assume : h(heartbeat rate ) > wH (w:write time, H:# of cache hops)

2) More complex topology – 3-level caching hierarchy– The basic relative trends is unaffected– BINV’s advantage are greatly reduced in WD case compared with

the RD case



3) More complex workload – Table 6, 7– Until now, Poisson workload used– Compound pages : the page contains multiple objects, reading and

writing processes that are heavy-tailed and processes that are uniformly distributed

– Trace-driven workload consisting of the read sequence of a single page extracted from a real trace-> Poisson model with an average of one modification per hour

The popular page : write-dominated, unpopular page : read-dominated



4) The effect of packet losses – Table 8, 9– Both invalidations and pushed updates : via unreliable multicast– Invalidations are less vulnerable to packet loss than pushes– Increases the bandwidth and response time for all the protocols– Staleness and stale hit rate are a little increased.

5) Related work– It takes less or the same B.W. as ATTL while achieving the same l

evel of page staleness and resulting in much less server load and client response time

– Single-page workload : precise effect of different reading and writing processes

– Average staleness– Operating regimes with much lower staleness measures than previ

ous studies


Additional design issues

Clock skew Finite cache Failure recovery Direct request Multiple hierarchies and Multi-Homing Supplying service to a subset of pages Deploying in existing cache hierarchies


Conclusion

Web cache consistency protocol based on invalidation– Previous work, multicast invalidation with volume lease +

incorporating them within a caching hierarchy

Heartbeat rate h > the writing rate * the # of hops => The invalidation approach is very effective in keeping pages relatively fresh

Pages are write-dominated => offers few advantage Pages are read-dominated => significant reduction in

server hit counts and client response time In both cases, similar or less B.W. than the TTL style

protocol


Critiques

Strong Point– Proposed scalable web cache consistency architecture

: caching hierarchy and application-level multicast routing to convey the invalidation

– Demonstrated technically feasible : consistency arch.– Well organized contents

Weak point– Use a set of relatively stable and well-managed caching hierarchie

s

Critiques– where the root cache should be located.– The imbalance architecture of tree. –> simple architecture is better

A Scalable Web Cache Consistency Architecture

Documents

Transcript of A Scalable Web Cache Consistency Architecture