Refreshment Policies for Web Content Caches

Edith Cohen

AT&T Labs-Research

Haim Kaplan

Tel-Aviv University

Presenting: Edith Cohen

Web Content Caches

www.cnn.com

AS

AS

ASProxy cache

Proxy cache

HTTP Freshness Control

• Cached copies have limited freshness lifetime (time since dispatched from origin until expiration)

• Expired copies must be validated before they can be used.

Body(content)

headerCache-directives

HTTP Cache Serving a Request

•No cached copy GET a fresh copy •Stale cached copy If-Modified-Since GET a fresh copy

•“Not-Modified” update header •“Modified” update content and header

•Fresh cached copy

GET www.cnn.com/WEATHER/

“hits” and “misses”

hit-rate: c-hit/(c-hit+c-miss)freshness-rate: f-hit/c-hit

f-hit f-miss c-miss

Remote RTTs (latency…)

X X

Bandwidth usage to

remote servers

X

“traditional”: c-hit (hit) (miss)

Why Pre-Validate ?

latency(c-miss) > latency(f-miss) >> latency(f-hit)• freshness rate is 50%-70% (f-hits/c-hits)

• 90%-95% of IMS GET requests return “Not Modified”

•Low freshness rate impedes cache ability to reduce user-perceived latency•Pre-validating (IMS GET) requires little bandwidth

How to Pre-Validate ?• Strong consistency [….]

– requires protocol, Web-server support

• Predictive pre-validations [….]– Require per-user or related-objects statistics

(volumes), possibly server-support.

• Cache refreshment policies– Refresh selected cached objects as they expire

– Implementation that resembles cache replacement policies; no need for Web-server/protocol support

Passive Vs. Proactive

Passive:

Proactive:

Requests:Freshness Lifetime Duration:

hitmiss to origin

Refreshment policies• What to refresh and how often?

– By policy, based on: recency, frequency, freshness-lifetime...

• Tradeoff: increased traffic reduced latency

We define several natural policies and evaluate them using trace-based simulations.

Some vendors incorporate ad-hoc policies.

Refreshment Policies

• For each item D, maintain credit(D)• When D expires:

– If credit(D)>0• Validate(D) • credit(D) -- /* decrement credit(D) */

• When D is requested:– Update credit(D) (according to policy)

Policies• passive : credit(D) = 0• recency(k): each request sets credit(D)=k• freq(k): if current request is a miss under

passive, do credit(D) += k• th-freq(h) refresh if #misses_passive(t) > h*(t-t0)/T• opt(k):

T

tt

T

tt nextnext Dcreditkif expexp )(,

over

head

(va

l ida

t ion

spe

r el

i min

ated

f-m

iss )

fraction of f-misses eliminated

Simulation results (NLANR)

Summary

• Refreshment is simple and effective– No external support, no involved prediction models

– Built-in destination overhead control (per-object: number of requests bounds number of validations).

• Frequency-based policies outperform Recency-based policies.

• 25%, 50% of f-misses can be eliminated with 1,2 extra validations per eliminated miss.

Future

• Minimizing pre-validations overhead – Refresh off-peak, group objects with same server.

• Refreshment policies and predictive pre-validations differ in implementation and scope (different sets of eliminated f-misses)– Refreshment exploits locality: effective on f-misses

occurring within few freshness-lifetime durations after previous request.

– Predictive pre-validations exploit correlations between objects.

Potential for co-deployment