Computer Science Technical Report Archive

USC Computer Science Technical Reports, no. 713 (1999)

(USC DC Other)

USC Computer Science Technical Reports, no. 713 (1999)

PDF

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content W orld Wide W eb Cac hing T rends and T ec hniques
Greg Barish Katia Obraczk a
USC Information Sciences Institute
Admiralt yW a y Marina del Rey CA USA
fb arish katia gisie du
Abstract
Academic and corp orate comm unities ha v e b een dedicat
ing considerable eort to W orld Wide W eb cac hing When
correctly deplo y ed W eb cac hing systems can lead to signif
ican t bandwidth sa vings serv er load balancing p erceiv ed
net w ork latency reduction and higher con tenta v ailabili t y In this pap er w e surv ey stateoftheart cac hing designs
and implemen tation s W e presen t a taxonom y of arc hitec
tures and describ e some of their design tec hniques
In tro ductio n
As the In ternet con tin ues to gro w in p opularit y and size so
ha v e the scalabilit y demands on its infrastructure Exp o nen tial gro wth without scalabili t y solutions will ev en tually
result in prohibitivenet w ork load and unacceptable service
resp onse times
It is w ellkno wn that the primary reason whyIn ter
net trac has increased is due to the surge in p opularit y
of the W orld Wide W eb sp ecicall y the high p ercen tage
of HTTP trac T o b etter understand this gro wth rate
consider that studies conducted less than v ey ears ago
rev ealed that of In ternet trac originated from FTP
requests Ho w ev er within the last y ear it w as sho wn
that HTTP activityhad gro wn to accoun t for somewhere
bet w een of all In ternet trac The App eal of W eb Cac hing
The unparalleled gro wth of the In ternet in terms of to
tal b ytes transferred among hosts coupled with the sud
den dominance of the HTTP proto col suggest m uchcan
b e lev eraged through W orld Wide W eb cac hing hereafter
called w eb cac hing tec hnology Sp ecicall y w eb cac hing
b ecomes an attractiv e solution b ecause it represen ts an ef
fectiv e means for reducing bandwidth demands impro ving
w eb serv er a v ailabil i t y and reducing net w ork latencies
Deplo ying cac hes close to clien ts can reduce o v erall bac k
b one trac considerably Cac he hits eliminate the need to
con tact the originating serv er Th us additional net w ork
comm unication can b e a v oided
T o impro vew eb serv er a v ailabilit ycac hing systems can
also b e deplo y ed in a rev erse fashion suc hasinthe re v erse pro xy serv er approac h describ ed in section where
cac hes are managed on b ehalf of con tentpro viders who
w an t to impro v e the scalabili t y of their site under existing
or an ticipated demand In these cases cac hes not only im
pro v e the a v ailabil i t y and faulttolerance of their asso ciated
w eb serv ers but also act as load balancers
Cac hing can impro v e user p erceptions ab out net w ork
p erformance in t wow a ys First when serving clien ts lo
cally cac hes hide widearea net w ork latencies On a lo cal
cac he miss the clien t request will b e serv ed b y the original
con tentpro vider In this case serv erside cac hes reduce re
quest serving time b y balancing serv er load and impro ving
serv er a v ailabil it y as discussed ab o v e
Second temp orary una v ailabil i t y of the net w ork can
b e hidden from users th us making the net w ork app ear to
b e more reliable Net w ork outages will t ypically not b e
as sev ere to clien ts of a cac hing system since lo cal cac hes
can b e lev eraged regardless of net w ork a v ailabil i t yThis
will esp ecially hold true for ob jects
whic h are temp oral
in nature suc hasisoc hronous deliv ery of m ultimedia data
lik e video and audio where consisten t bandwidth and re
sp onse times are particularl y imp ortan t
Though w eb cac hing oers m uc h hop e for b etter p er
formance and impro v ed scalabili t ythere remain a n um ber
of ongoing issues P erhaps primary among these is ob ject
in tegrit y if an ob ject is cac hed is the user guaran teed that
the cac hed cop y is uptodate with the v ersion on the origi
nating serv er Other issues include use of HTTP co okies
to p ersonalize v ersions of iden ticall y named URLs con ten t
securit y and the ethics of cac hing Op en issues are not the
fo cus of this pap er rather w e simply pro vide a taxonom y
of designs and tec hniques whichare a v ailable to da y The Need for a Surv ey
W eb cac hing is a rapidly ev olving eld whic h is one of the
k ey factors that motiv ated us to pro duce this surv eyIt is
dicult to k eep up with recen t adv ances since there are a
n um b er of ongoing eorts b oth industrial and academic
man y of whichcon tain solutions based on emerging w eb
standards suc h as p ersisten t connections and XML
W eb cac hing is also a y oung industry in whic ha n um ber
of commercial v endors pushing new solutions either ha v e
direct ties to researc h systems or are arc hitected b y individ
uals with notable researc h bac kgrounds Th us commercial
solutions often con tain aggressiv e and unique arc hitectures
The surv ey presen ted here serv es to capture a snapshot
of curren t design trends and tec hniques Its purp ose is not
to compare one solution against another but instead to
iden tify common designs and put them in con text
Outline
This pap er is organized as follo ws The next section de
scrib es sev eral distinct w eb cac hing arc hitectures In Sec
tionw e summarize v arious cac he deplo ymen t options
some deplo ymen ts go handinhand with the cac hing sys
tem arc hitecture whereas some arc hitectures allowfor a
v arietyofdeplo ymen t options Section fo cuses on com
mon design tec hniques found in man y existing arc hitec
tures In App endix A w e briey discuss the dicult yin
In this pap er w eb ob jects are usually the building blo c ks of a
w eb page A giv en page ma y con tain sev eral ob jects the HTML for
the page itself an em b edded picture a video a Ja v a applet etc
Most W eb URLs con tain sev eral distinct ob jects
iden tifying metrics of cac he eectiv eness and sp ecically
address recentw ork on b enc hmarking to ols Finallyin
App endix B w e elab orate on related net w orking comp o
nen ts whic h augmen t existing cac he deplo ymen t strategies
to impro v e scalabili t y Cac hing Arc hitectures
Pro xy Cac hing
Apro xy cac he serv er in tercepts HTTP requests from clien ts
and if it nds the requested ob ject in its cac he it returns
the ob ject to the user If the ob ject is not found the cac he
go es to the ob jects home serv er the originating server on b ehalf of the user gets the ob ject p ossibly dep osits it
in its cac he and nally returns the ob ject to the user
Pro xy cac hes are usually deplo y ed at the edges of a
net w ork ie at compan y or institutional gatew a yrew all
hosts so that they can serv e a large n um ber of in ternal
users The use of pro xy cac hes t ypically results in wide
area bandwidth sa vings impro v ed resp onse time and in
creased a v ailabil it y of static w ebbased data and ob jects
Standalone pro xy conguration is sho wn in Figure a
Notice that one disadv an tage to this design is that the
cac he represen ts a single p oin t of failure in the net w ork
When the cac he is una v ailabl e the net w ork also app ears
una v ailabl e to users Also this approac h requires that all
user w eb bro wsers b e man ually congured to use the appro
priate pro xy cac he Subsequen tly if the serv er is una v ail
able due to a long term outage or other administrative
reason all of the users m ust recongure their bro wsers in
order to use a dieren t cac he
Bro wser autoconguration is a recen t trend whichma y
alleviate this problem The IETF recen tly review ed a pro
p osal for a W eb Pro xy Auto disco v ery Proto col WP AD
a means for lo cating nearb ypro xy cac hes WP AD
relies on resource disco v ery mec hanisms including DNS
records and DHCP to lo cate an Automatic Pro xy Cong
uration APC le
One nal issue related to the standalone approac hhas
to do with scalabili t y As demand rises one cac he m ust
con tin ue to handle all requests There is no w aytody namically add more cac hes when needed as is p ossible with
transparen t pro xy cac hing describ ed b elo w
Rev erse Pro xy Cac hing
An in teresting t wist to the pro xy cac he approachis the no tion of r everse pr oxy c aching in whic hcac hes are deplo y ed
near the origin of the con ten t instead of near clien ts This
is an attractiv e solution for serv ers or domains whichex p ect a high n um b er of requests and w an t to assure a high
lev el of qualit y of service Rev erse pro xy cac hing is also a
useful mec hanism when supp orting w eb hosting farms vir
tual domains mapp ed to a single ph ysical site an increas
ingly common service for manyIn ternet service pro viders
ISPs
Note that rev erse pro xy cac hing deplo ymen t is totally
indep enden t of clien tside pro xy cac hing In fact they ma y
coexist and collectiv ely impro veW eb p erformance from
the user net w ork and serv er p ersp ectiv es
T ransparen t Cac hing
T ransparentpro xy cac hing eliminates one of the big dra w
bac ks of the pro xy serv er approac h the requiremen tto
congure w eb bro wsers T ransparentcac hes w ork byin ter
cepting HTTP requests TCP trac destined to p ort and redirecting them to w eb cac he serv ers or cac he clus
ters This st yle of cac hing establishes a p oin t at whic h
dieren t kinds of administrativecon trol are p ossible for
example deciding ho w to load balance requests across m ul
tiple cac hes
The strength of transparentcac hing is also its main
w eakness it violates the endtoend argumen tb y not main
taining constan t the end p oin ts of the connection This is
a problem when an application requires that state is main
tained throughout successiv e requests or during a logical
request in v olvin g m ultiple ob jects
The ltering of HTTP requests from all outb ound In
ternet trac adds additional latency F or example
cac hes deplo y ed in conjunction with La y er L switc hes
rely on the fact that these switc hes in tercept all trac
whic h is directed at p ort and send all other trac di
rectly to the W AN router
There are t wow a ys to deplo y transparen t pro xy cac hing
at the switchlev el and at the router lev el Routerbased
transparentpro xy cac hing Figure b uses p olicybased
routing to direct requests to the appropriate cac hes F or
example requests from certain clien ts can b e asso ciated
with a particular cac he
In switc hbased transparen tpro xy cac hing Figure c
the switc h acts as a dedicated load balancer Switc hes
are generally less exp ensiv e than routers Switc hbased
transparency is also often view ed as more attractiv e than
routerbased transparency b ecause there is not the addi
tional o v erhead that p olicybased routing incurs
The use of L switc hes for transparen t cac hing is an
example of ho w related net w ork comp onen ts pla y a role in
the eectiv eness of a w eb cac hing solution F or transparen t
cac hing these switc hes pro vide a form of lo cal load balanc
ing There are other switc hes and solutions for lo cal load
balancing as w ell as solutions for global load balancing
The use of related net w ork comp onen ts for this purp ose is
co v ered in more detail in App endix B
AdaptiveW eb Cac hing
Adaptivew eb cac hing views the cac hing problem as
aw a y of optimizing global data disseminatio n Ak ey
problem adaptiv e cac hing targets is the hot sp ot phe
nomenon where v arious shortliv ed In ternet con tentcan o v ernigh t b ecome massiv ely p opular and in high demand
Adaptivecac hing consists of m ultiple distributed cac hes
whic h dynamically join and lea v e cac he groups referred to
as c ache meshes based on con ten t demand Adaptivit y
and the selforganizing prop ert y of meshes is a resp onse
to those scenarios in whic h demand for ob jects gradually
ev olv es and those in whic h demand spik es or is otherwise
unpredictably high or lo w
Adaptiv e cac hing emplo ys the Cac he Group Manage
men t Proto col CGMP and the Con ten t Routing Proto
col CRP CGMP sp ecies ho w meshes are formed and
ho w individual cac hes join and lea v e those meshes In
general cac hes are organized in to o v erlapping m ulticast
groups whic h use v oting and feedbacktec hniques to es
timate the usefulness of admitting or excluding mem b ers
from that group The ongoing negotiation of mesh forma
tion and mem b ership results in a virtual top ology CRP is used to lo cate cac hed con ten t from within the
existing meshes It can b e said that CRP is a more deter
Figure a standalone b routertransparen t and c switc htransparen tpro xy cac hing
ministic form of hierarc hical cac hing whic h tak es adv an
tage of the o v erlapping nature of the meshes as a means
for propagating ob ject queries b et w een groups as w ell as
propagating p opular ob jects throughout the mesh This
tec hnique relies on m ulticast comm unication b et w een cac he
group mem b ers and mak es use of URL tables to in tel
ligen tly determine to whicho v erlapping meshes requests
should b e forw arded
One of the k ey assumptions of the adaptivecac hing ap
proac h is that deplo ymen t of cac he clusters across adminis
trativ e b oundaries is not an issue If the virtual top ologies
are to b e the most exible and ha v e the highest c hance of
optimizing con ten t access then administrativ e b oundaries
m ust b e relaxed so that groups form naturally at prop er
p oin ts in the net w ork
Push Cac hing
As describ ed in the k ey idea b ehind push cac hing is
to k eep cac hed data close to those clien ts requesting that
information Data is dynamically mirrored as the originat
ing serv er iden ties where requests originate F or example
if trac to a w est coast based site started to rise b ecause
of increasing requests from the east coast t ypical of what
happ ens on w eekda ys at am EST the w est coast site
w ould resp ond b y initiating an east coast based cac he
As with adaptivecac hing one main assumption of push
cac hing is the abilityto launchcac hes whichma y cross
administrative b oundaries Ho w ev er push cac hing is tar
geted mostly at con ten t pro viders whic h will most lik ely
con trol the p oten tial sites at whic h the cac hes could b e de
plo y ed Unlik e adaptiv e cac hing it do es not attempt to
pro vide a general solution for impro ving con ten t access for
all t yp es of con ten t from all pro viders
A recen t study regarding the eectiv eness of cac he
hierarc hies noted that w ellconstructed pushbased algo
rithms can lead to a p erformance impro v ementof up to
This study also notes the general dilemma that
push cac hing encoun ters forw arding lo cal copies of ob
jects incurs costs storage transmission but in the end
p erformance and scalabili t y are only seen as impro v ed if
those ob jects are indeed accessed
Activ e Cac hing
The WisW eb pro ject at the Univ ersit y of Wisconsin Madi
son is exploring ho w cac hing can b e applied to dynamic
do cumen ts Their motiv ation is that the increasing
amoun t of p ersonalized con ten t mak es cac hing suc h infor
mation dicult and not practical with curren tpro xy de
signs
Indeed a recen t study of a large ISP trace rev ealed
that o v er of clien t HTTP requests con tained co okies
whic h are HTTP header elemen ts t ypically indicating that
a request b e p ersonalized As w eb serv ers b ecome more
sophisticated and customizable and as onetoone mark et
ing ecommerce strategies proliferate the In ternet the
lev el of p ersonalizatio n is an ticipated to rise
Activecac hing uses applets lo cated in the cac he to cus
tomize ob jects that could otherwise not b e cac hed When
a request for p ersonalized con ten t is rst issued the origi
nating serv er pro vides the ob jects and an y asso ciated cac he
applets When subsequen t requests are made for that same
con ten t the cac he applets p erform functions lo cally at the
cac he that w ould otherwise more exp ensiv ely b e p er
formed at the originating serv er Th us applets enable cus
tomization while retaining the b enets of cac hing
Cac he Deplo ymen t Options
There are three main cac he deplo ymentc hoices those
whic h are deplo y ed near the con ten t consumer consumer
orien ted near the con tentpro vider pro viderorien ted
and those whic h are deplo y ed at strategic p oin ts in the
net w ork based on user access patterns and net w ork top ol
ogy and conditions Belo ww e discuss eac h of these options
adv an tages and disadv an tages
P ositioning cac hes near the clien t as is done in pro xy
cac hing includin g transparen tpro xy cac hing has the ad
v an tage of lev eraging one or more cac hes to a user comm u
nit y If those users tend to access the same kind of con ten t
this placemen t strategy impro v es resp onse time b y b eing
able to serv e requests lo cally Cac hes p ositioned near the con tentpro vider on the
other hand whic h is what is done in rev erse pro xy cac hing
and push cac hing impro v e access to a logical set of con
ten t This t yp e of cac he deplo ymen t can b e critical to
dela ysensitiv econ ten t suc h as audio or video P ositioning
cac hes near or on b ehalf of the con tentpro vider allo ws the
pro vider to impro v e the scalabili t y and a v ailabil i t y of con
tent butisob viously only useful for that sp ecic pro vider
An y other con tentpro vider m ust do the same thing
Of course there are compromises b et w een pro vider
orien ted and consumerorien ted cac he deplo ymen ts F or
example resource sharing and securit y constrain ts p ermit
ting is ma y b e p ossible for m ultiple corp orations to to
share the same clien tside cac hes through a common ISP Also one can en vision media h ubs suc h as Broadcastcom
pro viding con ten tbased cac hing on b ehalf of the actual me
dia pro viders Finally the use of b oth consumerorien ted
and pro viderorien ted cac hing tec hniques is p erhaps the
most p o w erful and eectiv e approac h since it com bines
the adv an tages of b oth while lo w ering the disadv an tages of
eac h
The last approac h dynamic deplo ymentof cac hes at
net w ork c hok e p oin ts is a strategy em braced b y the adap
tiv e cac hing approac h Although it w ould seem to pro vide
the most exible t yp e of cac he co v erage it still w ork in
progress and to the b est of the authors kno wledge there
ha v e not b een an y p erformance studies demonstrating its
b enets The dynamic deplo ymen t tec hnique also raises
imp ortan t questions ab out the administrativ e con trol of
these cac hes what impact w ould net w ork b oundaries ha v e
on cac he mesh formation
Finally a discussion ab out cac he deplo ymentw ould not
b e complete without noting the capabiliti es of bro wsers to
do cac hing on a p eruser basis using the lo cal le system
Ob viously while this is p erhaps useful for a giv en user it
do es not aid in the global reduction of bandwidth or decline
in a v erage net w ork latency for common w eb ob jects
Design T ec hniques
Cac hing systems are generally ev aluated according to three
metrics sp eed scalabilit y and reliabil it y There are a
v ariet y of design tec hniques on whic h man y commercial
and academic systems rely in order to impro v e p erformance
in these resp ects
Hierarc hical Cac hing
Hierarc hical cac hing w as pioneered in the Harv est Cac he The basic idea is to ha v e a series of cac hes hierarc hi
cally arranged in a treelik e structure and to allo w those
cac hes to lev erage from eac h other when an ob ject request
arriv ed and the receiving cac he did not ha v e that ob ject
Usually in hierarc hical designs child cac hes can query
p ar ent cac hes and c hildren can query eac h other but par
en ts nev er query c hildren This promotes an arc hitecture
where information gradually lters do wn to the lea v es of
the hierarc h y In a sense the adaptiv e cac hing approac h
also uses cac he hierarc hies in the form of cac he groups to
diuse information from dynamic hotsp ots to the outlying
cac he clusters but these hierarc hies are p eerbased the
paren tc hild relationshi ps are established p er information
ob ject Th us in one case a cac he group migh t act as a
paren t for a set of information ob ject X but also act as a
c hild or in termediary no de for information ob ject Y
With hierarc hical cac hes it has b een observ ed that par
en t no des can b ecome hea vily sw amp ed during c hild query
pro cessing Commercial cac hes suc h as NetCac he emplo y
clustering to a v oid this sw amping eect In tercac he Comm unication
W eb cac hing systems tend to b e comp osed of m ultiple dis
tributed cac hes to impro v e system scalabili t ya v ailabili t y or to lev erage ph ysical lo calit y In terms of scalabilit y and
a v ailabil it yha ving m ultiple distributed cac hes p ermits a
system to deal with a high degree of concurrentclientre quests as w ell as surviv e the failure of some cac hes during
normal op eration In terms of ph ysical lo calit y assuming
that bandwidth is constan t simply ha ving cac hes closer in
pro ximit y to certain groups of users ma y b e an eectiv e
w a y to reduce a v erage net w ork latencies since there is of
ten a correlation b et w een the lo cation of a user and the
ob jects requested
Regardless of wh y a logical cac he system is comp osed
of m ultiple distributed cac hes it often desirable to al
lo w these cac hes to query eac h other Distributing ob
jects among cac hes also allo ws load balancing and p er
mitting subsequentin tercac he comm unication allo ws the
o v erall logical system to ecien tly resolv e requests in ter
nally There are v ew ellkno wn proto cols for in tercac he
comm unication ICP cac he digests CRP CARP and W CCP Among these ICP has the longest history and is the most
mature It ev olv ed from the cac he comm unication in Har
v est and w as explored in more detail within Squid With
ICPcac hes issue queries to other cac hes to determine the
b est lo cation from whic h to retriev e the requested ob ject
The ICP mo del consists of a requestreply paradigm and
is commonly implemen ted with unicast o v er UDP Although it w as men tioned earlier that m ultiple dis
tributed cac hes can impro v e scalabili t y they can also im
p ede it as ICP later rev ealed One issue w as raised b y
whic h iden tied desirable limits to the depth of the cac he
hierarc h yF or example trees deep er than four lev els pro
vided noticible dela ys Another scalabilit y concern w as the
n um b er of ICP messages whic h could b e generated as the
n um ber of cac he p eers increased As noted in there
is a direct relationshi p b et w een the n um ber of p eer cac hes
and the n um b er of ICP messages sen t
That same study of ICP also raised the issue of m ul
ticast whic his a k ey enabling tec hnology of the adaptiv e
cac hing design Its CRP proto col uses m ulticast to query
cac he meshes Ov erlapping no des are used to forw ard unre
solv ed queries to other meshes in the top ologyT o optimize
the path of meshes to query adaptiv ecac hing uses CRP
to determine the lik ely direction of origin for the con ten t
Although m ulticast w as a prop osed solution suggested for
use with ICP when querying p eer cac hes the scalabili t y
implications of this approac h are still unclear
Another tec hnique related to cac hetocac he comm uni
cation is the notion of cac he digests suc h as those imple
men ted b y Squid and the Summary Cac he Digests
can b e used used to reduce in tercac he comm unication b y
summarizing the ob jects con tained in p eer cac hes Th us
request forw arding can b e more in tellig en t and more e
cien t This is similar to the notion of a URL routing table
whichisused b y the adaptivecac hing approac h also as a
w ayto more in telligen tl y forw ard a request
Finally there are t w o other proprietary proto cols Ciscos
W CCP and Microsofts CARP metho d When used with
devices suc h as the Cisco Cac he Engine W CCP en
ables HTTP trac to b e transparen tly redirected to the
Cac he Engine from net w ork routers W CCP has gradu
ally b een in tegrated in to Ciscos In ternet Op erating Sys
tem IOS whic h Cisco ships with its routers Recen tly Cisco announced it w as licensing W CCP to v endors suc h
as Net w ork Appliance and Inktomi
In con trast to ICPbased approac hes where cac hes can
comm unicate with eac h other to lo cate requested con ten t
Microsofts CARP is deterministic it uses a hashing
sc heme to iden tify whichpro xy has the requested infor
mation When a request comes in from a clien t a pro xy
ev aluates the hash of the requested URL with the name of
the pro xies it kno ws ab out and the one with the highest
v alue is realized to b e the o wner of that con ten t
The CARP hashrouting sc heme is prop osed as a means
for a v oiding the o v erhead and scalabilit y issues asso ciated
with in tercac he comm unication In that sense it is v ery
similar to the CRP proto col used b y the adaptivecac hing
pro ject as w ell as the cac he digest approachc hampioned
b y b oth Summary Cac he and Squid All of these eorts
attempt to reduce in tercac he comm unication
HashBased Request Routing
Hashbased routing is used to p erform load balancing
in cac he clusters It uses a hash function to map a k ey suc h as the URL or domain name of originating serv er to
a cac he within a cluster Go o d hash functions are critical
in partitioning w orkload ev enly among cac hes or clusters
of cac hes F or example NetCac he uses MDindexed URL
hash routing to access clusters of p eer c hild cac hes whic h
do not ha veo v erlapping URLs Since hashing can b e used as the basis for cac he selec
tion during ob ject retriev al hashbased routing is seen as
an in tercac he comm unication solution Its use can reduce
or eliminate the need for cac hes to query eac h other F or
example in the Microsoft CARP metho d cac hes nev er
query eac h other Instead requests are made to cac hes as
a function of the hashing the URL k ey There are also scenarios in whic h hashbased routing is
used only to p oin t the caller in the dir e ction of the con ten t
This can b e the case for v ery large cac hing infrastructures
suc h as the t yp e describ ed b y the adaptivecac hing pro ject
When lo cating remote con ten t hashbased routing can b e
used as a means to p oin t the lo cal cac he in the direction
of other cac hes or cac he meshes whic h either ha vethe
ob ject or can get it from other cac hes or the originating
serv er
Optimized Disk IO
Man y systems esp ecially those whic h are commercial ha v e
sp en t substan tial time tuning their disk IO treating the
ob ject cac he as one do es a high p erformance database Net
Cac he and No v ells ICS for example either use
APIs pro vided b y their o wn custom microk ernel or use lo w
o v erhead APIs pro vided b y the host op erating system
More sp ecic disk IO optimizations include impro ving
the spatial lo calit y of ob jects and using inmemory data
structures to a v oid disk IO altogether as in The
former tec hnique tak es adv an tage of logically related con
ten t in order to determine where on the disk to place that
con ten t Inmemory data structures suc h as hash tables
can b e used to quic kly determine if an ob ject has b een
cac hed if querying these data structures nds that the ob
ject has indeed b een cac hed disk op erations can b egin to
actually lo cate the ob ject if not already in RAM Other
wise disk access can b e a v oided altogether and the ob ject
can b e fetc hed from the originating serv er Th us these
data structures summarize the con ten ts of a cac he so that
costly IO op erations can b e a v oided when p ossible
Microk ernel Op erating Systems
Microk ernel arc hitectures ha v e emerged as a mec hanism for
optimizing cac he p erformance sp ecicall y in terms of im
pro ving resource allo cation task execution and disk access
and transfer times The general motiv ation for microk ernel
based approac hes has b een that general purp ose op erating
systems suc h as UNIX and Windo ws NT are not suitable
for the sp ecialized needs of optimized w eb cac hing These
general purp ose op erating systems handle resources suc h
as pro cesses and le handles in a co op erativ ew a y whereas
cac hing systems ha v e sp ecic needs ab out ho w these re
sources are managed
A t least v e notable v endors ha veem braced microk ernel
arc hitectures and these systems share a
n um b er of common features In some cac hes are mo deled
as nite state mac hines They are ev en t driv en allo wing
them to scale b etter than threadbased approac hes those
whic h are commonly used for deplo ymen t on general pur
p ose op erating systems These microk ernels also optimize
access to disk resources b y increasing the n um b er of le
handles for eac h pro cess as w ell as creating v ery fast APIs
for disk hardw are access
Con ten t Prefetc hin g
Prefetc hing refers to the retrieving data from remote serv ers
in an ticipatio n of clien t requests Prefetc hing can b e clas
sied as either lo calbased or serv erhin tbased The
former relies on data suc h as reference patterns to c ho ose
what to prefetc h next The latter uses data accum ulated
bythe serv er suc h as whic h ob jects ha v e b een frequen tly
requested b y other clien ts One disadv an tage of the serv er
hin t approachis that in tegration b et w een clien t and serv er
is more complicated since there needs to b e some co or
dination related to the comm unication of the hin ts from
the serv er to the clien t Also as noted b y there are
three distinct prefetc hing scenarios prefetc hing b et w een
clien ts and serv ers b et w een clien ts and pro xies and b e t w een pro xies and serv ers Sev eral studies ha v e
attempted to quan tify the b enets of prefetc hing for cac hing
for these v arious scenarios
Kro eger et al lo ok ed at prefetc hing b et w een pro xies
and serv ers They found that without prefetc hing pro xy
cac hing with an unlimited cac he size resulted in a reduction in latency With a basic prefetc hing strategy in
place that reduction in latency could b e impro v ed to
and with a more sophisticated prefetc hing strategy serv er
hin ts that n um b er could b e further impro v ed to b e As migh t b e exp ected ha ving a go o d prefetc hing algorithm
and higher prefetc h lead times pla ys an imp ortan t role in
optimizing the prots asso ciated with this tec hnique
P admanabhan and Mogul lo ok ed at prefetc hing b e t w een clien ts and serv ers and classied their gains of in
terms of ob ject access times creating three categories of
suchgains zer o smal lor lar ge access times F or exam
ple that study found that without prefetc hing these w ere
zero access time small and large With
prefetc hing that distribution impro v ed to and
That study also found that in addition to the sig
nican t impro v emen t in ob ject access time under prefetc h
ing there w as not an increase in the v ariabili tyof those
retriev als
Astudy byCao et al explored scenarios in whic h
pro xy cac hes pushed con ten t out to clien ts connected through
lo wbandwidth links ie mo dem users Th us this ex
plored the issues of prefetc hing b et w een clien ts and pro xies
That study sho w ed that the a v erage latencies encoun tered
b y these t yp es of clien ts could b e reduced byo v er
Their design w as based on a pro xy that predicted whic h
do cumen ts a user migh t access in the near future and then
pushed those do cumen ts out to the users lo cal cac he during
p erio ds of idle net w ork activit y This study ac kno wledged
that their results w ere based on sim ulations constructed
from actual mo dem trace logs where the a v erage band
width b et w een clien ts and pro xies w as Ksec
Cac he Consistency Metho ds
Cac he consistency is concerned with ensuring that the cac hed
ob ject do es not reect stale or defunct data F or pur
p oses of our discussion stale or defunct data refers to
lo cally cac hed ob jects whic h are either a no longer are
equiv alen t to the ob ject on the originatin g serv er a phe
nomenon disco v ered through comparison of ob ject c hec k
sums or b ha v e since b een obsoleted As iden tied b y
Dingle and P artl there are four w ellkno wn cac he
consistency main tenance tec hniques to deal with detect
ing suc h instances clien t p olling in v alidatio n callbac ks
timetoliv e and ifmo diedsinc e With clien t p olling cac hes timestamp eac h cac hed ob
ject and p erio dicall y compare the cac hed ob ject timestamp
with that of the original ob ject at the originating serv er
Out of date ob jects are discarded and new er v ersions are
fetc hed when necessary This approachis v ery similar
to the timestampbased le system cac he consistency ap
proac h emplo y ed b y Sun Net w ork File System NFS Instead of ha ving clien ts p erio dical ly c hec k for inconsis
tencyin v alidati on callbac ks rely on the originating serv er
to iden tify stale ob jects The serv er m ust then k eep trac k
of the pro xies that are cac hing its ob jects and con tact
these pro xies when ob jects c hange On one hand callbac ks
impro v e cac he consistency as w ell as sa v e net w ork band
width b y not requiring clien ts to p erio dicall y p oll serv ers
On the other hand there are clear scalabilit y issues and
priv acysecurit y concerns regarding this approac h since
serv ers need to trac k cac hes for eac h cac hed ob ject
Similar to the limited life of pac k ets in transit on com
m unication net w orks cac hed ob jects can also ha v e a time
toliv e TTL When expired these ob jects are dump ed
and new copies are fetc hed The TTL approac hdoes not
guaran tee that an ob ject whichnev er c hanges will not b e
con tin ually refetc hed but it do es signican tly limit the re
p eated retriev al Adaptiv e TTL is a tec hnique whereb y
the TTL of an ob ject is up dated within the cac he when a
cac he hit o ccurs
Ifmo diedsince is a recen tv ariation to TTLbased con
sistency Squid migrated to this approac h whic hisde mand driv en In this scenario cac hes only in v alidate ob
jects when they are requested and their expiration date has
b een reac hed
Despite the concerns listed ab o v e rep orted that in
v alidation and adaptiv e TTL are comparable in terms of
net w ork trac clien t resp onse times and serv er CPU w ork
load These metho ds w ere found to b e preferable o v er the
other t w o approac hes giv en situations where consistency
is imp ortan t F urthermore it w as also found that c ho osing
to supp ort strong consistency o v er w eak consistency do es
not necessarily result in increased net w ork bandwidth
Conclusions
W eb cac hing is an imp ortanttec hnology whic h can im
pro vecon tenta v ailabili t y reduce net w ork latencies and
address increasing bandwidth demands In this pap er w e
ha v e presen ted sev eral cac hing arc hitectures deplo ymen t
options and sp ecic design tec hniques Weha vesho wn
that while there are man y approac hes to designing and
deplo ying cac hes some issues suc hasin tercac he comm u
nication remain common among them
There remain a n um ber of open issues in w eb cac hing
Some of the tec hnical issues include con ten t securit ythe
practicalit y of handling dynamic and realtime data and
dealing with complex functional ob jects suc has Ja v a pro
grams The next few y ears will lik ely b e exciting ones as
w eb cac hing researc hers and v endors deal with these c hal
lenges
Ac kno wledgemen ts
W e are grateful to Gary T omlinson for making his ICS
rep ort quic kly a v ailable to us and to P eter Danzig for his
helpful discussions
A Measuring P erformance
Giv en all the existing cac hing solutions ho w do es one de
cide whic h one is the b est Ultimately the eectiv eness of
aw eb cac hing system will b e largely dep enden t on the need
and constrain ts of the deplo y er A giv en arc hitecture migh t
inheren tly b e more suitable and th us p erform b etter for
certain scenarios
F or example corp orations ma yha v e signican t success
with basic pro xy serving and ma y not view bro wser con
guration as an issue p erhaps the compan y enforces use
of a particular bro wser whic h supp orts autoconguration
Other deplo y ers suc hasISPs ma y prot more from router
or switc hbased transparen t cac hing approac hes deplo y ed
at the edges of their net w orks Finally there are con ten t
pro viders who ha venocon trol o v er ho w their con tentis
cac hed at the clien t side they merely w an t to deliv er
their con ten t in a scalable manner Th us rev erse pro x
ying or push cac hing migh t b e most suitable giv en those
constrain ts
Regardless of deplo ymen t needs there still is a demand
to quan tify the p erformance of v arious cac hing systems
Similar to the standard SPEC b enc hmarks used to mea
sure the p erformance of m ultipro cessor arc hitectures and
the TPC family of b enc hmarks used with database sys
tems the cac he dev elop er and user comm unit y recen tly
recognized the need for standard b enc hmarking to ols to
ev aluate the p erformance of cac he systems Cac hesp ecic
p erformance metrics include amoun t of bandwidth sa v ed
resp onse time hit rate and v arious scalabilit y metrics
In this section w e briey describ e t wow ellkno wn cac he
benc hmarks the Wisconsin Pro xy Benc hmark and P oly
graph
A The Wisconsin Pro xy Benc hmark
The Wisconsin Pro xy Benc hmark WPB w as one of
the rst publicly a v ailable cac he b enc hmarking ito ols Its
distinguishi ng features include supp ort for studying the ef
fect of adding disk arms and the eect of handling lo w
bandwidth mo dembased clien ts One in teresting nding
through use of WPB w as that latency adv an tages due to
cac hing w ere essen tially erased when considering the o v er
all prot to mo dembased clien ts
While WPB addresses a n um b er of imp ortantbenc h
marking requiremen ts suc h as initial supp ort for temp oral
lo calit y and some abilit y to generate load on w eb serv er
pro cesses it has some limitations These include lac kof
supp ort for mo deling spatial lo calit y p ersisten t HTTP connections DNS lo okups and realistic URLs The WPB
has b een used to b enc hmark sev eral pro xy cac hes includ
ing some of the researc h and commercial systems men
tioned in
A P olygraph
P olygraph is a recen tly dev elop ed publicly a v ailable
cac he b enc hmarking to ol dev elop ed b y NLANR It can sim
ulate w eb clien ts and serv ers as w ell as generate w orkloads
that try to mimic t ypical W eb access
P olygraph has a clien t and a serv er comp onen t eac h
of whic h uses m ultiple threads to generate or pro cess re
quests This allo ws P olygraph to sim ulate concurrentre quests from m ultiple clien ts to m ultiple serv ers P olygraph
can generate dieren tt yp es of w orkload to sim ulate v ari
ous t yp es of con ten t p opularit yF or example requests can
b e generated whic h ob ey a Zipflik e distribution whic his
largely b eliev ed to b e a go o d estimate of real w eb usage
patterns More recen tlyP olygraph has b een pla ying an increas
ing role in holding op en b enc hmark W eb Cac hing Bak e
o s as a w a y of inspiring the dev elopmentcomm unit y and
encouraging comp etition to w ards go o d cac hing solutions
A summary of their study comparing a n um b er of commer
cial and academic systems can b e found at B Related Net w ork Comp onen ts
The eectiv eness of w eb cac hing is in part aected b ythe
related net w ork comp onen ts whic h are deplo y ed in con
junction with a cac he cac he cluster or w eb serv er W e
no w summarize a few t yp es of lo cal and global load bal
ancing solutions whic h augmen t existing cac he systems
B Lo cal Load Balancers
Lo cal load balancing is concerned with impro ving the scal
abilit ya v ailabil i t y and reliabil ityof w eb serv ers or w eb
cac hes Incoming requests are in tercepted and redirected
to one mem b er of a group of serv ers or cac hes all of whic h
exist in a common geographic lo cation By splitting the
requests among mem b ers of a group one serv er or cac he is
not forced to handle all incoming requests Th us suc hser vices can scale b etter and are more robust no single p oin t
of failure Lo cal load balancing usually in v olv es distribut
ing requests according to some load balancing algorithm
suchas r oundr obin or le astc onn e cti on s One w ayto ac hiev e lo cal load balancing is to use L switc hes in a transparen t cac hing en vironmen t In that
case clien t outb ound requests can b e in tercepted and redi
rected to w ards mem b ers of a cac he cluster Another t yp e of
lo cal load balancing can b e ac hiev ed b y using L switc hes
whic h p erform a more seman tic st yle of load balancing
The Alteon A CEDirector and CA CHEDirector switc hes
represen t examples of ho w L switc hing can impro veserv er
and cac he load balancing Another example switc histhe
Lo calDirector from Cisco whic his t ypically deplo y ed to
distribute incoming load up on m ultiple w eb serv ers or re
v erse pro xy cac hes
Recen t alternativ es to Lbased switc hing ha vebeen
Lswitc hing and L switc hes whic h supp ort L nd L pro
cessing The former t yp e pro vides the same functionalit y
as an L switc h but also includes sophisticated partition
ing supp ort and comes with IP lters that normally need
to b e added to L switc hes Again Alteon is example of
av endor whichmak es adv anced L switc hesthatalso
supp ort L and L pro cessing
More recen tlyLa y er L switc hing has emerged as
another load balancing alternativ e This t yp e of switc h
Figure Requestbased Routing via L switc hing
ing approac hes loadbalanci ng from a more seman tic lev el
One example is the Arro wp oin t Con ten t SmartSwitc h CSS
Lik e a standard L switc h the CSS p erformas load balanc
ing for b oth clien tbased or serv erbased deplo ymen t strate
gies Ho w ev er CSS op erates ab o v e the transp ort la y er and
balances based on requested con tentt yp e
F or instance on the clien t side CSS can b e congured
to redirect static HTTP requests to a lo cal cac he cluster
and b ypass cac hing for dynamic HTTP requests When
balancing load among con tentserv ers CSS can distingui sh
among dieren t higherlev el proto cols lik e HTTPSSH and NTTP and div ert them to the appropriate serv er or
group of serv ers F urthermore requests can b e redirected
based on con ten tbased qualit yofservice F or example as
Figure sho ws administrators can redirect SSH requests
les to dieren tserv ers F ulllmen t of those requests ma y
p er request t yp e ie requests for video les ma ybe slo wly
lled whereas text les are handled m uc h quic k er since the
latter is easier to transmit than the former
Distributed W eb serving solutions maycom bine cac hing
L and L switc hing T ak e for example the case of a ISP
that also pro vides W eb hosting services An L switc h can
b e placed in fronteac h group of replicated serv ers eac h
of whic h serving dieren tcon ten t An L switc h can b e
placed at the en trance of the ISP so as to div ert dieren t
con ten t to the appropriate Lreplicated serv er group
B Global Load Balancers
Global load balancers are similar to lo cal load balancers
in that they ha v e the goal of impro ving p erformance and
scalabilityHo w ev er instead of distributin g requests among
mem b ers of a group whic h are geographicall y lo cal to one
another global load balancers usually distribute requests
to serv ers or cac hes whichare ne ar the clientto ac hiev e
lo w er a v erage net w ork latencies as w ell as to impro v e scal
abilit y F or example if an organization has w eb serv ers de
plo y ed throughout the w orld a global load balancer can
determine the appropriate host based on ph ysical lo ca
tion for a giv en clien t request and return the IP address
of that serv er to the clien t Since bro wsers often cac he DNS
en tries lo cal POPs also do this etc rep eated requests b y
aclientto a giv en logical In ternet address will con tin ue to
result in those requests b eing forw arded to the most lo cal
serv er
Ciscos Distributed Director is one example of a global
load balancer When a clien t request is issued it is initially
directed to w ards a primary DNS serv er This request ev en
tually reac hes the lo cal DNS serv er for that logical site A t
this p oin t the lo cal DNS serv er con tacts the Distributed
Director and determines the IP address of the geographi
cally appropriate serv er for handling the request This IP
acdress is then sen t bac k to the clien t and will most lik ely
b e cac hed for futher use
Radw ares Cac he Serv er Director CSD is another global
load balancing solution dedicated to w ards impro ving cac he
fault tolerance Consider the case of a con tentpro vider
whose replicated serv ers are lo cated at dieren tIn ternet
sites A CSD is placed at eac h site as a fron tend to the
lo cal set of replicated serv ers Eac h CSD runs a lo cal DNS
serv er and exc hanges net w ork pro ximityas w ell as serv er
load information with the other CSDs A CSD maps a
clien t requests host name to one of the ISP sites IP ad
dress It mak es its decision based on where the request
originated and its curren t net w ork and serv er load infor
mation ab out itself and the other serv er clusters
References
J Almeida and P Cao Measuring pro xy p erformance with the
wisconsin pro xy b enc hmark T e chnic al R ep ort Com
puter Scienc es Dept Univ of Wisc onsinMadison
M Baen tsc h L Baum G Molter S Rothkugel and P Sturm
W orld wide w eb cac hing the application lev el view of the
in ternet IEEE Communic ations Magazine vol June C M Bo wman P Danzig D R Hardy U Man b er and
M Sc h w artz Harv est A scalable customizable disco v ery and
access system T e chnic al R ep ort CUCS University of
Color ado Boulder L Breslau L F an P Cao G Phillips and S Shenk er The
implications of zipfs la w for w eb cac hing International Con
fer enc e on Web Caching R Caceres P Danzig D Jamin and D Mitzel Characteris
tics of WideArea TCPIP Con v ersations Pr o c e e dings of SIG
COMM R Caceres F Douglis A F eldmann and M Rabino vic h W eb
pro xy cac hing The devil is in the details Pr o c e e dings of the
Workshop on Internet Server Performanc e P Cao and C Liu Main taining strong cac he consistency in
the w orld wide w eb Pr o c e e dings of Thir d International Con
fer enc e on Web Caching P Cao J Zhang and Kevin Beac h Activ ecac he Cac hing dy
namic con ten ts on the w eb Pr o c e e dings of IFIP International
Confer enc e on Distribute d Systems Platforms and Op en Dis
tributedPr o c essing A Chankh un tho d P Danzig C Neerdaels M Sc h w artz and
K W orrell A hierarc hical in ternet ob ject cac he Pr o c e e dings
of the USENIX T e chnic al Confer enc e Cisco Cisco Systems Cac he Engine Series Q and A httpw ww cisc o c om K Clay and D W essels ICP and the Squid W eb Cac he P Danzig Net w ork Appliance NetCac he White P ap er Arc hi
tecture and Deplo ymen t httpww wnet ap pc om A Dingle and T P artl W eb cac he coherence Fifth Interna
tional World Wide Web Confer enc e L F an P Cao J Almeida and AZ Border Summary
cac he A scalable widearea w eb cac he sharing proto col
Computer Scienc es Dep artment University of Wisc onsin
Madison P Gauthier J Cohen M Dunsm uir and C P erkins The w eb
pro xy autodisco v ery proto col httpww wi etf or gi nternet dr aftsdr a ftiet fwr e cwp ad t xt J Gw ertzman and M Seltzer The case for geographical push
cac hing Fifth A nnual Workshop on Hot Op er ating Systems InfoLibria Dynacac he whitepap er A vailable fr om
wwwinfolibria c om
TM Kro eger DE Long and JC Mogul Exploring the
b ounds of w eb latency reduction from cac hing and prefetc h
ing Pr o c e e dings of the Symp osium on Internet T e chnolo gies
and Systems I Melv e In tercac he comm unication proto cols IETF WREC
Working Gr oup Dr aft S Mic hel K Nguy en A Rosenstein L Zhang S Flo yd and
V Jacobson Adaptiv ew eb cac hing to w ards a new global
cac hing arc hitecture Computer Networks ISDN Systems Sun Microsystems NFS Net w ork File System
V P admanabhan and JC Mogul Impro ving h ttp latency Se c ond World Wide Web Confer enc e
D P epp ers and M Rogers The one to one future Building
relationships one customer at a time Double day K Ross Hash routing for collections of shared w eb cac hes
IEEE NetworkNo v em b erDecem b er
K Ross and V V alloppillil Cac he arra y routing proto col v
IETF WREC Working Gr oup Dr aft A Roussk o v P olygraph httpp ol ygr a ph ir c ache net A Roussk o v and D W essels First w eb cac he bak eo F ourth
International Web Caching Workshop Results a v ailable
at h ttpbak eo
ircac he netbak eo
Cac heFlo w T ec hnologies W eb cac hing white pap er
httpww w ca che ow com R T ew ari M Dahlin HM Yin and JS Ka y Bey ond hier
arc hies Design considerations for distributed cac hing on the
in ternet T e chnic al R ep ort TR University of T exas A t
A ustin K Thompson G Miller and R Wilder Widearea in ternet
trac patterns and c haracteristics Pr o c e e dings of Thir d In
ternational Confer enc e on Web Caching G T omlinson D Ma jor and R Lee Highcapacit yin ternet
middlew are In ternet cac hing system arc hitectural o v erview
Se c ond Workshop on Internet Server Performanc e

Abstract (if available)

Linked assets

Computer Science Technical Report Archive

Conceptually similar

PDF

USC Computer Science Technical Reports, no. 662 (1997)

PDF

USC Computer Science Technical Reports, no. 595 (1994)

PDF

USC Computer Science Technical Reports, no. 714 (1999)

PDF

USC Computer Science Technical Reports, no. 738 (2000)

PDF

USC Computer Science Technical Reports, no. 707 (1999)

PDF

USC Computer Science Technical Reports, no. 739 (2001)

PDF

USC Computer Science Technical Reports, no. 652 (1997)

PDF

USC Computer Science Technical Reports, no. 638 (1996)

PDF

USC Computer Science Technical Reports, no. 735 (2000)

PDF

USC Computer Science Technical Reports, no. 660 (1997)

PDF

USC Computer Science Technical Reports, no. 658 (1997)

PDF

USC Computer Science Technical Reports, no. 708 (1999)

PDF

USC Computer Science Technical Reports, no. 854 (2005)

PDF

USC Computer Science Technical Reports, no. 680 (1998)

PDF

USC Computer Science Technical Reports, no. 651 (1997)

PDF

USC Computer Science Technical Reports, no. 737 (2000)

PDF

USC Computer Science Technical Reports, no. 689 (1998)

PDF

USC Computer Science Technical Reports, no. 695 (1999)

PDF

USC Computer Science Technical Reports, no. 693 (1999)

PDF

USC Computer Science Technical Reports, no. 705 (1999)

Description

Greg Barish and Katia Obraczka. "World wide web caching: Trends and techniques." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 713 (1999).

Asset Metadata

Creator Barish, Greg (author), Obraczka, Katia (author)

Core Title USC Computer Science Technical Reports, no. 713 (1999)

Alternative Title World wide web caching: Trends and techniques (title)

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)

Tag OAI-PMH Harvest

Format 8 pages (extent), technical reports (aat)

Language English

Unique identifier UC16270836

Identifier 99-713 World Wide Web Caching Trends and Techniques (filename)

Legacy Identifier usc-cstr-99-713

Format 8 pages (extent),technical reports (aat)

Rights Department of Computer Science (University of Southern California) and the author(s).

Internet Media Type application/pdf

Source 20180426-rozan-cstechreports-shoaf (batch), Computer Science Technical Report Archive (collection), University of Southern California. Department of Computer Science. Technical Reports (series)

Access Conditions The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Repository Email csdept@usc.edu

Inherited Values

Title Computer Science Technical Report Archive

Coverage Temporal 1991/2017

Repository Email csdept@usc.edu

Repository Name USC Viterbi School of Engineering Department of Computer Science

Repository Location Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089

Publisher Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)