Freshness-driven adaptive caching for dynamic content Web sites

www.elsevier.com/locate/datak

Data & Knowledge Engineering 47 (2003) 269–296

Freshness-driven adaptive caching for dynamic contentWeb sites

Wen-Syan Li *, Oliver Po, Wang-Pin Hsiung, K. Selc�uk Candan,Divyakant Agrawal

C&C Research Laboratories––Silicon Valley, NEC USA, Inc., 10080 North Wolfe Road, Suite SW3-350,

Cupertino, CA 95014, USA

Received 30 October 2002; received in revised form 9 April 2003; accepted 14 May 2003

Abstract

Both response time and content freshness are essential to e-commerce applications on the Web. One

option to achieve good response time is to build a high performance Web site by deploying the state of art

IT infrastructures with large network and server capacities. With such a system architecture, freshness ofthe content delivered is limited by the network latency since when users receive the contents, the contents

may have changed at the server. With the wide availability of content delivery networks, many e-commerce

Web applications utilize edge cache servers to cache and deliver dynamic contents at locations much closer

to users, avoiding network latency. By caching a large number of dynamic content pages in the edge cache

servers, response time can be reduced, benefiting from higher cache hit rates. However, this is achieved at

the expense of higher invalidation cost. On the other hand, a higher invalidation cost leads to a longer

invalidation cycle (time to perform invalidation check on the pages in caches) at the expense of freshness of

cached dynamic content. In this paper, we propose a freshness-driven adaptive dynamic content caching

technique, which monitors response time and invalidation cycle length and dynamically adjusts caching

policies. We have implemented the proposed technique within NEC�s CachePortal Web acceleration so-

lution. We have conducted experiments to evaluate effectiveness of the proposed freshness-driven adaptive

dynamic content caching technique. The experimental results show that the proposed technique consistently

maintains the best content freshness to users. The experimental results also show that even a Web site with

dynamic content caching enabled can further benefit from deployment of our solution with improvement of

* Corresponding author. Tel.: +1-408-863-6008; fax: +1-408-863-6099.

E-mail addresses: [email protected] (W.-S. Li), [email protected] (O. Po), [email protected] (W.-P.

Hsiung), [email protected] (K. Selc�uk Candan), [email protected] (D. Agrawal).

0169-023X/$ - see front matter � 2003 Elsevier B.V. All rights reserved.

doi:10.1016/S0169-023X(03)00093-4

mail to: [email protected]

270 W.-S. Li et al. / Data & Knowledge Engineering 47 (2003) 269–296

its content freshness up to 10 times especially during heavy user request traffic and long network latency

delay.

� 2003 Elsevier B.V. All rights reserved.

Keywords: Dynamic content; Web acceleration; Freshness; Response time; Network latency

1. Introduction

Response time and content freshness are essential to e-commerce Web sites. In businessterms, the brand name of an e-commerce site is correlated to the type of experience users re-ceive. The need for accounting for users� quality perception in designing Web servers fore-commerce systems has been highlighted by [1]. Snafus and slow-downs at major Web sitesduring special events or peak times demonstrate the difficulty of scaling up e-commerce sites.Slow response times and down times can be devastating for e-commerce sites as reported in astudy by Zona Research [2] on the relationship between Web page download time and userabandonment rate. The study shows that only 2% of users will leave a Web site (i.e. aban-donment rate) if the download time is less than 7 s. However, the abandonment rate jumps to30% if the download time is around 8 s. The abandonment rate reaches 70% as download timesexceed 12 s. This study clearly establishes the importance of fast response times to an e-com-merce Web site to retain its customers. In technical terms, ensuring the timely delivery of freshdynamic content to end-users and engineering highly scalable e-commerce Web sites for specialpeak access times put heavy demands on IT staff. This load is compounded by the ever-changing complexity of e-commerce applications.

For many e-commerce applications, Web pages are created dynamically based on the currentstate of a business, such as product prices and inventory, stored in database systems. Thischaracteristic requires e-commerce Web sites to deploy and integrate Web servers, applicationservers, and database systems at the backend. A basic system architecture of database-driven Websites consists of the following components:

1. A Web server (WS) which receives user requests and delivers the dynamically generated Webpages.

2. An application server (AS) that incorporates all the necessary rules and business logic to inter-pret the data and information stored in the database. AS receives user requests for HTMLpages and depending upon the nature of a request may need to access the DBMS to generatethe dynamic components of the HTML page.

3. A database management system (DBMS) to store, maintain, and retrieve all the necessary dataand information to model a business.

When the Web server receives a request for dynamic content, it forwards the request to theapplication server along with its request parameters (typically included in the URL string). TheWeb server communicates with the application server using URL strings and cookie information,which is used for customization, and the application server communicates with the database using

W.-S. Li et al. / Data & Knowledge Engineering 47 (2003) 269–296 271

queries. When the application server receives such a request from the Web server, it processes itand it may access the underlying databases to extract the relevant information needed to dy-namically generate the requested page.

To improve the response time, one option is to build a high performance Web site to improvenetwork and server capacity by deploying the state of art IT infrastructure. However, without thedeployment of dynamic content caching solutions and content delivery network (CDN) services,dynamic contents are generated on demand. In this case, all delivered Web pages are generatedbased on the current business state in the database. However, when users receive the contents, thebusiness state could already have changed due to the network latency.

The alternative solution is to deploy network-wide caches so that a large fraction of requests canbe served remotely rather than all of them being served from the origin Web site. This solution hastwo advantages: serving users via a nearby cache closer to the users and reducing the traffic to theWeb sites. Many content delivery network services [3,4] provideWeb acceleration services. A studyin [5] shows that CDN indeed has significant performance impact. However, for many e-commerceapplications, HTML pages are created dynamically based on the current state of a business, such asproduct prices and inventory, rather than static information. As a result, the time to live (TTL) forthese dynamic pages cannot be estimated in advance. Therefore, content delivery by most CDNs islimited to handling static portions of the pages and streaming media, rather than the full spectrumof dynamic content that constitutes the bulk of the e-commerce Web sites.

Applying caching solutions for Web applications and content distribution has received a lot ofattentions in the Web and database communities [6–17]. These provide various solutions to ac-celerate content delivery as well as techniques to assure the freshness of the cached pages. Notethat since Web content is delivered through the Internet, the content freshness can only be assuredrather than being guaranteed.

For the Web sites that are dynamic content caching enabled, by caching more dynamic con-tents in edge cache servers, response time can be improved through the benefit of higher cache hitrates and low network latency. However, in a database-driven Web site, databases must bemonitored so that the cached pages which are impacted by database content changes can be in-validated or refreshed in a timely manner. As a result, caching a large number of Web pages atedge cache servers to yield fast response time are achieved at the expense of invalidation cycles.Thus, it requires more computational resources and time to complete invalidation checking. Onthe other hand, when invalidation cycle is long, the freshness of cached pages cannot be main-tained at a desirable level. Furthermore, many parameters, such as database update rates, userrequest rates, and network latency, also have effect on user response time and length of invali-dation cycles.

How to architect Web sites and tune caching policy dynamically to serve fresh content inshort response time is a complex issue. In this paper, we focus on the issue of how to maintain thebest content freshness that can be assured for a given set of user request rate and database up-date rate. We propose an adaptive dynamic content caching technique that monitors re-sponse time and invalidation cycle as feedback for dynamic adjustment of caching policy.By considering the trade-off of invalidation cycle and response time, it maintains the best contentfreshness to the users. The rest of this paper is organized as follows. In Section 2, we discussissues in caching policy tuning specifically for dynamic content Web sites. In Section 3, we give an


overview of our proposed solution. In Section 4 we describe the dynamic content invalida-tion schemes used in NEC�s CachePortal. In Section 5, we describe dependency betweenuser request response time and invalidation cycles. In Section 6 we identify how to finetune caching policy for balancing response time and invalidation cycles for maintaining fresh-ness. We also present experimental results that evaluate effectiveness of our proposed techniquefor ensuring content freshness. Section 7 summarizes related work and Section 8 concludes thepaper.

2. Issues in caching policy tuning for dynamic content Web sites

In this section, we present the problem formulation and give an overview of our proposedsolution. We start with the description of an e-commerce Web site system architecture that isdynamic content caching enabled.

There are multiple tiers in the content delivery infrastructure where cache servers can be de-ployed. They include the following:

• Database caches, which are placed between application servers and database systems for accel-eration of database access via JDBC or ODBC interfaces. The work addressed in [18] focuseson the caching issues in this tier.

• DBCaches, which are usually placed in data centers. DBCaches are considered mirror data-bases and they are used by applications hosted in the data centers. By generating requested con-tents from locations close to users, content delivery can be accelerated. The work described in[15,19] focus on caching issues in this tier.

• Content page caches, which are reverse caches and can be placed close to users, functioning asedge caches, or in front of Web servers, functioning as frontend caches. The study of the impactof cache positions on the user response time in [17] validates that edge caches have many ad-vantages over front end caches, such as fast and more predictable user response time. The workdescribed in [6,7,9,13,14,16,20] focus on caching issues in this tier. In the scope of this paper, wefocus on the content delivery network architectures where cache servers are placed at the net-work edges close to users.

Fig. 1 shows the architecture and data flows of a database-driven e-commerce Web site whereNEC�s CachePortal technology [7,9,17] is deployed. The architecture is very similar to that oftypical e-commerce Web sites, except for the two CachePortal components, Sniffer and In-validator. The CachePortal technology enables dynamic content caching by utilizing Sniffer toderive URL/DB Query Mapping, the relationships between cached pages and the database con-tents that are used to generate these pages. The Invalidator is responsible for monitoring databasechanges by scanning database update log. The database changes are monitored periodically by theInvalidator and then it performs invalidation checking process to identify the cached pages whichare impacted by the database changes during the current period.

Note that the knowledge about dynamic content is distributed across three different servers: theWeb server, the application server, and the database management server. Consequently, it is notstraightforward to create a mapping between the data and the corresponding Web pages auto-

Invalidator

Sniffe

URL/Query Mapping

Edge Cache

End Users

Web Server

Application Server

Content Change

in the same or

nearby network

Constructing

Utilizing

Messages

DB Queries

Cookies Page content (HTML)

DB Query Results

Monitoring

Cookies Page content (HTML)

Program parameters Invocation:

Captureing

Request:

URL+Parameters

Internet

Request: URL+Parameters Page content (HTML)Cookies

nearby netwok

in the same or

Invalidation

DBMS

Fig. 1. A database-driven e-commerce site with dynamic content caching enabled.


matically in contrast to the other approaches [21–24], which assume such mappings are providedby the system designers. The detailed descriptions on automated construction of such URL anddatabase query mapping are given in [7]. In Section 4, we give a detailed description of the in-validation process.

In this configuration, user requests are directed to the edge cache that is close to the requestingusers. If there is a cache hit, the requested content will be delivered to the users from the cache.Otherwise requests are forwarded to the origin Web server. Note that in our implementation, edgecaches behave as both reverse proxies (if there is a hit) and proxies (if there is a miss so that therequests are forwarded). Since edge cache servers are close to the users so that the network latencybetween the cache servers and the users can be disregarded compared with the network latencybetween the cache servers and the origin Web sites.

Let us define the main three terms that have impact on the freshness of delivered contents asfollows:


Response time at edge cache servers: This is the round trip time for requests that are served atthe edge cache servers (as a result of a cache hit). The response time from edge caches is expectedto be extremely fast.

Response time at origin Web sites: This is the round trip time for requests that are served at theorigin Web servers (as a result of a cache miss).

Invalidation cycle: This is the time required to process invalidation checks for all the pages inthe cache servers.

The invalidation cycle is impacted by the following factors:

• the update rates in database systems;• the number of pages in the cache servers; and• the correlation between the pages in the cache servers (in terms of the query statements used to

generate these pages).

More detailed information will be given in Section 4 in the discussion of query type conceptsand consolidation of invalidation.

For Web sites that do not deploy any dynamic content caching solution, all pages need to bedynamically generated at the origin Web site. The content freshness that such a system can assureis the response time at the Web sites. For example, if the response time for a request at a Web siteis 10 s on the average the Web page can be fresh, but since the database content can change after theWeb page is generated, the assured freshness of the page (i.e. age) is 10 s!

For Web sites that deploy dynamic content caching solutions, some pages are dynamicallygenerated at the origin Web site, but the majority of the pages are delivered from the cache server.Since the database content changes need to be reflected to the pages in the cache server, invali-dation check needs to be performed periodically or on demand to ensure content freshness. In theseWeb sites, the content freshness that can be assured is the maximum of (1) the response time fromoriginWeb sites, (2) the response time from edge caches, and (3) the length of the invalidation cycle.Note that since the response time from edge caches is much faster than the response timefrom either the origin Web sites or the length of invalidation cycles, the content freshness that canbe assured is the larger of the response time from origin Web sites and the length of the invalidation

cycle.Depending on the caching policy, traffic patterns, cache hit rates, server load, and database

update rates, sometimes the response time at origin Web sites can be much longer than the in-validation cycle time. In Fig. 2(b), we show a system configuration that caches few pages. As aconsequence, it is expected to has a short invalidation cycle; at the expense of slow response timewhen there is a cache miss since the Web site is carrying a heavy load. On the other hand, thesystem configuration in Fig. 2(c) has a different caching policy and caches a large number of Webpages at its edge caches. This configuration provides fast response time for all requests. Whenthere is a cache hit, the response time is naturally very fast. When there is a cache miss, the re-sponse is still fast since the Web site has lighter work load as most of the requests are serveddirectly from the edge cache servers. However, this configuration and its caching policy has po-tentially low content freshness since it will take much longer time to complete the necessary in-validation check for all the pages in the cache servers.

Fig. 2. Response time and freshness of delivered content by various system architectures: (a) without dynamic content

caching, (b) with dynamic content caching enabled, (c) with dynamic content caching enabled, (d) deploying fresh-

nessdriven adaptive dynamic content caching, (e) higher response time at the Web site, (f) freshness assured at the new

equilibruium.



3. Solution overview

From Section 2, we learn that the freshness of requested pages can be ensured at the highestlevel when the hit rate is tuned to a point where the response time from the origin site and in-validation cycle for the cached pages are equivalent as shown in Fig. 2(d). In this paper,we propose a freshness-driven adaptive dynamic content caching technique. The proposed tech-nique aims at maintaining the best content freshness that a system configuration can supportand assure. Our technique does not ‘‘blindly’’ attempt to maintain the lowest average responsetime nor average content freshness. Instead it assures good content freshness: the deliveredcontent is either fresh or not older than a threshold (i.e. the assured content freshness) given by thesystem.

For the configuration in Fig. 2(b), the proposed freshness-driven adaptive caching wouldtune its caching policy by increasing the number of cached pages so that the traffic at the ori-gin Web site can be reduced until the response time at the origin Web site is close to the lengthof the invalidation cycle, where the assured freshness of delivered content is optimal. On theother hand, for the configuration in Fig. 2(c), the proposed freshness-driven adaptive cach-ing would decrease the number of pages cached at the edge cache servers so that invalidationcycles could be shorten until the response time at the origin Web site and the length ofthe invalidation cycle reach a new equilibrium as shown in Fig. 2(d). We define two terms asfollows:

• At the equilibrium, the length of invalidation cycle is the assured freshness and the responsetime at the origin Web site is the assured response time.

The equilibrium in Fig. 2(d); however, may change when the influential parameters change. Forexample, if network latency, database update rates, and user request rates increase, the responsetime at the origin Web site will increase accordingly (Fig. 2(red)). To reduce the response time atthe origin Web site, the freshness-driven adaptive caching will increase the number of cachedpages at the edge cache. Consequently, the request rate at the origin Web site is reduced (so is theresponse time) at the expense of invalidation cycle. Note that the equilibrium in Fig. 2(f) is higherthan the equilibrium in Fig. 2(d).

The proposed freshness-driven adaptive caching has various advantages. First, it allows thebest content freshness among these system architectures; with or without dynamic content cachingsolutions. Second, it also yields fast response times. Third, it provides assurance for both freshnessand response time as follows:

• the system does not serve the content that is older than the assured freshness; and• the system does not serve the content slower than the assured response time.

4. Invalidation checking process

In this section, we describe the invalidation process in the CachePortal technology:Consolidated Invalidation Checking, a method to enable invalidation checking process. In Section 5,


we will show the dependency between cache hit rates and invalidation cycles and how the invali-dation checking process can be tuned to achieve target cache hit rate; and consequently, desiredresponse time. We start by introducing an example database and terminology used later in thissection.

4.1. Concept of polling queries for invalidation checking

Assume that the database has the following two tables.

Car(maker, model, price)

Mileage(model, EPA)

Say that the following query Query1 has been issued to produce a Web page, URL1:

select maker, model, price

from Car

where maker¼ 00Toyota00;

Say, now we observe, based on the database log, that a new tuple (Toyota, Avalon, $25,000) isinserted into the table Car.Query1 only accesses the table Car, hence we can check if the new tuplevalue satisfies the condition stated in Query1. Since it satisfies the query, Query1 has been im-pacted and consequently URL1 needs to be invalidated or refreshed. Note that the update op-eration can be viewed as a delete operation followed by an insert operation. We can apply theprocedure just described to handle update operations.

Now assume the following query, Query2, has been issued to produce a Web page, URL2:

select Car.maker, Car.model, Car.price, Mileage.EPA

from Car, Mileage

where Car.maker¼ 00Toyota00 andCar.model¼Mileage.model;

Note that this query involves more than one table and there is a join operation. Now we ob-serve that a new tuple (Toyota, Avalon, $25,000) is inserted into the table Car. Since Query2 needsto access two tables, we first check if the new tuple value can satisfy the condition associated withonly the table Car stated in Query2. If it does not satisfy, we do not need to test the other con-dition and we know the new insert operation does not impact the query result of Query2 andconsequently URL2 does not need to be invalidated or refreshed.

If the newly inserted tuple does satisfy the condition associated with the table Car, we cannotdetermine whether or not the query result of Query2 has been impacted unless we check the rest ofthe condition associated with the table Mileage. To check whether or not the conditionCar.model¼Mileage.model can be satisfied, we need to access the table Mileage. To check thiscondition, we need to issue the following query, Query3, to the database:

select Mileage.model, Mileage.EPA

from Mileage

where 00Avalon00¼Mileage.model;


If the result of Query3 is non-empty, the query result for Query2 needs to be invalidated. Thequeries, such as Query3, that are issued to determine if certain query results need to be invalidatedare referred as polling queries.

4.2. Query types

We now introduce the terminology that is relevant to the proposed consolidated invalidationchecking:

• Query type: A query type is the definition of a query. It is a valid SQL statement which may ormay not contain variables. We denote a query type as QðV1; . . . ; VnÞ, where each Vi is a variablethat has to be instantiated by the application server before the query is passed to the DBMS.

• Bound-query type: A bound query type is a valid SQL statement which does not contain vari-ables. We denote a bound query type as Qða1; . . . ; anÞ, where each ai is a value instantiatedfor variable Vi . Queries that are passed by the application server to the DBMS are bound que-ries.

• Query instances: A query instance, is a bound query type with an associated request time stamp.We denote a bound query type as Qtða1; . . . ; anÞ, where t is the time at which application serverpassed the request to the DBMS.

Therefore, multiple query instances can have the same bound query type; and, multiple boundquery types may have the same query type.

If the Invalidator observes the following three query instances, Query4, Query5, and Query6, inthe log to generate user requested pages:


from Car

where maker¼ 00Toyota00;


from Car

where maker¼ 00Honda00;


from Car

where maker¼ 00Ford00;

we can derive a query type, Query_Type1 as:


from Car

where maker¼ $var;

Therefore, multiple query instances can have the same bound query type; and, multiple boundquery types may have the same query type. We can create a temporary table Query_Type1_ID torepresent the above three query instances, Query4, Query5, and Query6, as follows:


There are usually a limited number of query types designed for a Web-based application fore-commerce. For example, the above query type could be associated with a query interface thatallows users to specify car maker names to retrieve model and price information of the cars by thespecified car maker.

4.3. Consolidated invalidation checking

We now explain how to identify which query results have been impacted as a result of updatesto the database. Assume that there are three queries to be checked, Query4, Query5, and Query6.Let us also assume that the following four tuples are inserted to the database:

(Acura, TL, $30,000)(Toyota, Avalon, $25,000)(Honda, Accord, $20,000)(Lexus, LS430, $54,000)

Assume that we create a temporary table Delta for the content changes in the table Car. Onesimple way is to replace maker in Query4, Query5, and Query6 with Acura, Toyota, Honda, andLexus respectively. As a result, 12 (i.e. 3 · 4) polling queries need to be issued to perform inval-idation checking. Obviously this is not very efficient.

The other way is to consolidate a large number of required invalidation checks into more‘‘compact’’ form through transformation. For example, a single polling query, Query10, can beissued as follows:

select Query_Type1.QUERY_IDfrom Query_Type1, Delta

where Delta.Maker¼Query_Type1.QUERY_INSTANCE;

Query_Type1.QUERY_ID is a list of query results that need to be invalidated. In this example,Query4 and Query5 will be invalidated.

Now let us look at another query type. For example, the following two queries, Query11, andQuery12, are also in the log to generate user requested pages:


from Car, Mileage

where Car.maker¼ 00Toyota00and Car.model¼Mileage.model;

QUERY_ID QUERY_INSTANCE

Query4 Toyota

Query5 Honda

Query6 Ford



from Car, Mileage

where Car.maker¼ 00Ford00and Car.model¼Mileage.model;

we can derive a query type, Query_Type2 as:


from Car, Mileage

where Car.maker¼ $varand Car.model¼Mileage.model;

And we may create a temporary table Query_Type2_ID to represent the above two query in-stances as follows:

A single polling query, Query13, can be issued as follows to perform fully consolidatedchecking:

select Query_Type2.QUERY_IDfrom Car, Mileage, Query_Type2, Delta

where Car.maker¼Delta.Maker

and Car.model¼Mileage.model

and Delta.Maker¼Query_Type1.QUERY_INSTANCE;

Query_Type2.QUERY_ID is a list of query results that need to be invalidated. In this example,both Query11 and Query12 will be invalidated.

4.4. Summary

In this section, we described the invalidation checking scheme in CachePortal. In our currentimplementation, the full consolidation scheme is deployed at default to speed up the invalidationprocess. We summarize some important characteristics of the consolidated invalidation checkingschemes as follows:

• The invalidation cycle length is mainly impacted by the number of query types. The number ofquery types determine the number of polling queries that are executed for invalidation check.

• The number of query instances per query type is impacted by user request rate and request dis-tribution.

• The database update rates and the number of query instance per query type have relativelylower impact on the invalidation cycle length since they only increase query processingcomplexity for each query type rather than the number of processes for query processing.

QUERY_ID QUERY_INSTANCE

Query11 Toyota

Query12 Ford


• Network latency has no impact to the invalidation cycle since the Invalidator is usually de-ployed on the same machine as the DBMS. However, invalidation messages need to be sentout across the Internet. Since invalidation messages are sent out through a persistent connec-tion between the Invalidator and edge caches. The impact of network latency and connectiondelay on invalidating cached content is low.

In the next section, we conduct experiments to validate the above characteristics based onanalysis of invalidation process in this section.

5. Dependency between response time and invalidation cycle

In this section, we examine the dependency between the response time and the invalidationcycle length. We have conducted experiments to verify this dependency. We first describe thegeneral experiment setup that consists of databases, application servers, and network infra-structure that are used in the experiments.

5.1. General experimental setting

We used the following experimental setup in our evaluations:

• We used two heterogeneous networks that are available in the NEC�s facility in Cupertino, Cal-ifornia: one is used by the C&C Research Laboratories (referred to as CCRL) and the other oneis used by cacheportal.com (referred to as CP). Users and cache servers (edge caches in this set-ting) are located in CCRL while the Web server, application server, and DBMS are located inCP. The average number of hubs between CCRL and CP is 15. The average throughput mea-sured for CCRL–CP, CP–CP, and CCRL–CCRL connections are 84.7, 682.4 and 482.4 KB/srespectively. The average round trip time on CCRL–CP, CP–CP, and CCRL–CCRL connec-tions are 321, 1, and 2 ms respectively. To summarize, the experiment environment representsreal world networking characteristics: (1) connectivity within the same network is substantiallybetter than that across the Internet; and (2) there is network latency.

• Users and the edge cache server are located in the CCRL network. The Web server, applicationserver, and DBMS are located in the CP network. Thus, the network latency for cache-missedrequests is 321 ms.

• Oracle 9i is used as the DBMS and is on a dedicated machine. The database contains seven ta-bles with 1,000,000 rows each. The database update rate can be set as 5000, 10,000, and 15,000rows per table per minutes.

• The maximum number of pages that can be cached is 2,000,000 pages. These pages are gener-ated by queries that can be categorized into 200 query types. Thus, there are 10,000 pages(query instances) per query type.

• BEA WebLogic 6.1 is used for the WAS, and Apache is used as the edge cache server and theyare located in dedicated machines. All of the machines are installed an Pentium III 700 MHzone CPU PCs running Redhat Linux 7.2 with 1 GB of memory.


• The invalidation mode is set as ‘‘continuous’’. In the continuous invalidation mode, the Inval-idator will fetch a new block of database update log to start processing immediately after itcompletes an invalidation check cycle.

5.2. Correlation between number of query types and cache hit rates at the edge cache

The problem of cache replacement has been extensively studied. Many algorithms have beenproposed for general purpose caching, such as LRU and LFU. Some variations of these aredesigned specifically for cache replacement of Web pages. However, in the scope of dynamiccaching for a Web site, cache invalidation rates is an important factor since a high invalidationrate will lead to a potentially high cache miss rate in the future. As a result of the high miss rate,the WAS and DBMS have to handle a higher load to generate Web pages. Also, as a result of highinvalidation rate, the Invalidator component requires to handle more invalidation checking, issuemore polling queries to the DBMS, and send out more invalidation messages.

We have developed a self tuning cache replacement algorithm (ST) that takes into consid-eration (1) user access patterns, (2) page invalidation pattern, and (3) temporal locality of therequests. The caching priority of each page is re-calculated periodically. In the current imple-mentation, the priority is re-calculated every minute. Note that the frequency of re-calculationdoes have an impact on the cache hit rate. Potentially, the more often the caching priorities arere-calculated, the higher are the cache hit rates. The frequency of re-calculation should bedynamically adjusted by considering the trade-off between the benefit of higher hit rates and theadditional cost incurred due to frequent re-calculations.

The access rate and the invalidation rate is the access count and invalidation count within atime period. The caching priority of a page during a time period t, Caching priorityðtÞ, is calcu-lated as

ð1� aÞ � access rateinvalidation rate

þ a� Caching priorityðt � 1Þ

where a is the temporal decay factor whose value is between 0 and 1. A value of 1 for a makes thesystem treat all access patterns equally, while a value of 0 makes the system consider only theaccess patterns during the current time period. In the experiments the value of a is set to 0.8, whichyields the best results.

The intuition behind this formula is that it estimates the average number of accesses for the pagebetween any two successive invalidations. The higher this number the larger the benefit to keep thispage in the cache. After we calculate the caching priority for each pages, we then calculate thecaching priority of each query type in a similar way: we calculate their caching priority by ag-gregating the access rate and invalidation rate for all pages generated by the same query type.

Consequently, we are able to select only a small number of query types and cache pagesgenerated by these query types, but maintain a high hit rate at caches. Fig. 3 shows the correlationbetween the number of query types and the cache hit rates. As we can see in the figure, when weselect 20 query types (10% of all query types), the cache hit rate is close to 30%. And, when weselect 100 query types (50% of all query types), the cache hit rate is close to 80%. Additional studyon correlation between the cache hit rate and the invalidation rate can be found in [25] as well as

Fig. 3. Correlation between number of query types and cache hit rates.


how to select appropriate query types (i.e. a small number of query types) to monitor whileserving most of user requested pages.

For example, in the experiments conducted in this paper, we set 200 as the maximum number ofquery types. Note that a Web site may have more than 200 query types; however, we can identifyand monitor the 200 query types that will contribute to a high cache hit rate the most efficiently.

5.3. Effects of request rates and numbers of query types on invalidation cycles

As the summary in Section 4 states, the number of query types has the major impact to theinvalidation cycle since it directly determines the number of polling queries that must be executed.In the experiments, we vary the number of query types and measure the invalidation cycle timewhen the number of query types is 20, 60, 100, 140, and 180 respectively. Fig. 4 shows the ex-perimental results that illustrate the effects of the number of query types on the invalidation cycle.As the number of query types increases, so does the length of the invalidation cycle. Note that thepolling query for each query type takes two temporary tables to join: the query instance table andthe database change table. When the invalidation cycle is shorter, the database change table issmaller accordingly when query instance table remains the same. As a result, the polling queries forthe shorter invalidation cycle has lower query processing cost. Fig. 4 also shows that the requestrates have limited impact on the invalidation cycle although a higher request rate does put a heavierload on the DBMS where the invalidation checks are performed.

5.4. Effects of request rates and cache hit rates on request response time at the origin Web site

The next experiment we conducted is to measure the effects of cache hit rates and request rateson the response time at the origin Web site. Note that we do not present the effects of cache hit

Fig. 4. Effects of request rates and numbers of query types on invalidation cycles (database update rate¼ 5000 tuples

per table per minute).


rates and request rates on the response time at the edge cache server since the edge cache server(based on Squid implementation) is extremely scalable and fast to deliver small objects, like ca-ched dynamic content, within the same network.

In Fig. 5, we plot the response time at the origin Web site with respect to a set of differentrequest rates (i.e. from 40 requests per second to 680 requests per second) and different cache hit

Fig. 5. Effects of request rates and cache hit rates on request response time at the origin Web site (database update

rate¼ 5000 tuples per table per minute).


rates (i.e. 30%, 65%, 80%, 84%, and 88%). Note that since the cache hit rates are directly impactedby the numbers of query types, the cache hit rates of 30%, 65%, 80%, 84%, and 88% correspond tothe setup where the numbers of query types are 20, 60, 100, 140, and 180 respectively. The setupfor the experiments in Figs. 4 and 5 are the same, but we measure invalidation cycles in Fig. 4 andmeasure request response time in Fig. 5.

The experimental results in Fig. 5 indicate that request response time is much more sensitive tothe request rate than the length of invalidation cycles. When the request rate reaches a certainthreshold, the response time increases sharply.

5.5. Effects of network latency on request response time at the origin Web site

The network latency between users and the origin Web site is around 320 ms round trip time.Based on the network latency condition, we measure the request response time at the origin Website as shown in Fig. 5. In this experiment to measure the effects of network latency on requestresponse time at the origin Web site, we vary the edge cache hit rate so that the request rate at theorigin Web site changes according. In the experiment in this section, we fixed the cache hit rate as80% but varied the request rate and the network latency between users and the origin Web site(round trip time) as 160, 320, 480, 640, and 800 ms.

In Fig. 6, we plot the response time at the origin Web site with respect to a set of differentoverall request rates and network latency settings. The experimental results in the figure indicatethat request response time at the origin Web site is very sensitive to both request rate and networklatency. When the request rate reaches a certain threshold, the response time increases sharply.And, the response time increases at the faster rate with longer network latency. As we can seefrom the figure, the slop of the plot for the network latency of 160 ms is much steeper than that forthe network latency of 800 ms.

Fig. 6. Effects of request rates and network latency on request response time at the origin Web site (database update

rate¼ 5000 tuples per table per minute, hit rate¼ 80%).


5.6. Effects of database update rates on invalidation cycles and request response time

The next experiment we conducted is to measure the effects of database update rates on cacheinvalidation cycles and request response time. We repeated the experiments in Sections 5.3 and 5.4by varying the database update rate from 5000 tuples per table per minute to 10,000 and 15,000tuples per table per minute. Our observations based on the experimental results are as follows:

• The increase in the invalidation cycle length is almost proportional to the increase of the data-base update rate. This is expected as the polling query processing costs are proportional to thedatabase update rate, when the number of query instances is fixed. This is illustrated in Figs. 4,7, and 8. For example, when the number of query types is fixed to 40, increasing the database

Fig. 7. Effects of request rates and numbers of query types on invalidation cycles (database update rate¼ 10,000 tuples


Fig. 8. Effects of request rates and numbers of query types on invalidation cycles (database update rate¼ 15,000 tuples



update rate from 5000 to 10,000 per table per minute results in only 70% increase of the inval-idation cycle (i.e. increasing from 1.7 to 2.9 s).

• The database update rates have limited impact on the request response time. For example,when the database update rate increases from 5000 tuples per table per minute to 10,000 tuplesper table per minute, the request response time increases by about 10%. Although a higher data-base update rate puts a heavier load on the DBMS, the major portion of request response timeis network latency rather than server process latency. As a result, the effects of database updaterates to the request response time is very limited. This is illustrated in Figs. 4, 9, and 10.

Fig. 9. Effects of request rates and hit rates on invalidation cycles (database update rate¼ 10,000 tuples per table per

minute).

Fig. 10. Effects of request rates and hit rates on invalidation cycles (database update rate¼ 15,000 tuples per table per

minute).


6. Freshness-driven adaptive dynamic content caching

In this section, we describe the proposed freshness-driven adaptive dynamic content cachingfollowed by the discussion and analysis of the experimental results.

6.1. Adaptive caching policy

To achieve the best assured dynamic content freshness, we need to tune the caching policyso that the response time is close to the invalidation cycle in an equilibrium point. However,the response time and invalidation cycle can only be improved at the expense of each other.In Section 5, we found that response time can be impacted by (1) network latency, (2) requestrates, (3) database update rates, (4) invalidation cycle (frequency), and (5) cache hit rates. Net-work latency, request rates, and database update rates depend on the network infrastructure andapplication characteristics and hence cannot be controlled. However, we can ‘‘control’’ (i.e. tune)the frequency of invalidation cycles. Furthermore, the cache hit rate can be controlled by thenumber of cached query types (Figs. 9 and 10). We can derive the following adaptive cachingpolicy for maintaining request response time and invalidation cycle close to an equilibrium point:

• If the response time is larger than the length of the invalidation cycle, we can lower the requestresponse time by increasing the number of query types until the request response time and in-validation cycle reach an equilibrium point.

• If the invalidation cycle is longer than the request response time, we can lower the invalidationcycle by decreasing the number of query types until the request response time and invalidationcycle reach an equilibrium point.

Note that when the invalidation cycle is longer than the response time and we shorten thelength of the invalidation cycle by decreasing the number of query types, the increase of requestresponse time and the decrease of invalidation cycle will occur at the same time. As a result, anequilibrium point can be achieved fast. Similarly, when we increase the number of query types, thedecrease of request response time and the increase of invalidation cycle will occur at the sametime.

In the current implementation, the adaptive caching policy is deployed at the edge server. Theresponse time is measured at the cache server assuming that the round trip between users and thecache server (i.e. also functioning as a user side proxy) is negligible.

6.2. Experiments

We conducted a series of experiments to evaluate the proposed freshness-driven adaptivedynamic content caching technique. For the first 60 min of experiments, we created setups byvarying request rates and database update rates every 10 min while the network condition remainsthe same (network latency as 320 ms round trip). After the 60 min, we change the network latencyevery 10 min while the user request rate and database update rate are fixed. We then observed theeffects of our freshness-driven adaptive caching technique on maintaining the best freshness that

Fig. 11. Impact of adaptive caching on content freshness.


can be assured for a given system configuration and traffic and network conditions. In Fig. 11, weplot the response time as a dotted line and invalidation cycle as a solid line. The numbers next tothe dotted line are the number of query types being cached.

We observe that the sudden changes of the request rate will cause temporary imbalance ofresponse time and invalidation cycle. Especially the response time is very sensitive to the changesof request rates. As time moves on, the freshness-driven adaptive caching technique makes nec-essary adjustments to the number of query types; and this impacts the cache hit rate and theresponse time. As time elapses, the response time and invalidation cycle are shifted back to a newequilibrium point, which supports the best content freshness that can be assured.

From Fig. 11, we can see that the request response time at the origin Web site can be adjustedquickly since it is very sensitive to the cache hit rate. We also observe that the invalidation cyclecannot be adjusted as quickly. These observations are consistent with our experimental results inSection 5.

Next we compare the content freshness that can be assured by three different system configu-rations as follows:

1. a system configuration that does not deploy any dynamic content caching solution;2. a system configuration that is dynamic content caching enabled but that does not employ the

proposed freshness-driven adaptive caching technique; and3. a system configuration that is dynamic content caching enabled and that employs the proposed

freshness-driven adaptive caching technique.

In Fig. 12 we plot the larger of the response time and the invalidation cycle length at these threesystem configurations. This value gives the content freshness that a given system configuration can

Fig. 12. Comparisons of assured content freshness for three system configurations.


support for given request and database update rates. The figure shows the huge benefit providedby the proposed freshness-driven adaptive caching technique. The third configuration consistentlyprovides much fresher content than the two other configurations. Especially, during the heavytraffic conditions (i.e. during the periods of 10–20, 30–40, and 50–60 min) and the long networklatency delay condition (i.e. during the period of 70–80 min), the system configuration with thefreshness-driven adaptive caching supports content freshness up to 20 times better than thosewithout dynamic content caching. It also supports content freshness up to 10 times better thaneven those systems that already deploy dynamic content caching solutions. The experimentsstrongly show the effectiveness and benefits of the proposed freshness-driven adaptive cachingtechnique in providing fresh dynamic content.

6.3. Summary

In Fig. 16 we summarize the assured content freshness for the experimental results in Figs. 13–15 and the period of 60–80 min. The X -axis is the number of query types and the Y -axis is theassured content freshness (i.e. the maximum of response time and invalidation cycle). We plot theassured content freshness at different user request rates and database update rates with respect todifferent numbers of query types at the cache servers. We can see that the curves of the assuredcontent freshness are similar to the shape of a bowl. The best assured content freshness can beachieved at the bottom of the ‘‘bowl’’ which is circled. The proposed freshness-driven adaptivecaching technique continuously monitors response time and invalidation cycle to increase or todecrease the number of query types in the cache server so that the assured content freshness ismaintained at the the bottom of the ‘‘bowl’’.

Fig. 14. Response time and invalidation cycle for the period of 30–40 min (10,000 updates per second, 360 requests per

second).

Fig. 15. Response time and invalidation cycle for the period of 50–60 min (5000 updates per second, 45 requests per

second).

Fig. 13. Response time and invalidation cycle for the period of 10–20 min (15,000 updates per second, 550 requests per

second).


Fig. 16. Effects of adaptive caching on assured content freshness.


7. Related work

Issues related to caching of dynamic data have received significant attention recently [26,27].Applying caching solutions for Web applications and content distribution has also received a lotof attentions in the Web and database communities [7–12]. In citedy2002, Katsaros and Mano-lopoulos give summary of refresh, re-fetch, consistence maintenance technologies associated withWeb-powered databases.

Although a lot of research have been done on view maintenance [28,29] and constructions ofcomposite events, such as [30,31], we believe that it is an option limited to building and custom-izing a a Web site which has a limited number of distinct pages, such as the IBM Web site forOlympic Games [22–24]. In our system [7,9], we intend to support automated constructions of themapping between Web pages and queries that retrieve the database contents to generate suchpages. Dynamai [21] from Persistence Software is one of the first dynamic caching solution that isavailable as a product. However, Dynamai relies on proprietary software for both database andapplication server components. Thus it cannot be easily incorporated in existing e-commerceframework.

Other related works include [32,33] where authors propose a diffusion-based caching protocolthat achieves load-balancing, [34] which uses meta-information in the cache-hierarchy to improvethe hit ratio of the caches, [35] which evaluates the performance of traditional cache hierarchiesand provides design principles for scalable cache systems, and [36] which highlights the fact thatstatic client-to-server assignment may not perform well compared to dynamic server assignmentor selection.

SPREAD [37], a system for automated content distribution is an architecture which uses ahybrid of client validation, server invalidation, and replication to maintain consistency acrossservers. Note that the work in [37] focuses on static content and describes techniques to syn-chronize static content, which gets updated periodically, across Web servers. Therefore, in a sense,


the invalidation messages travel horizontally across Web servers. Other works which study theeffects of invalidation on caching performance are [38,39]. Consequently, there has been variouscache consistency protocol proposals which rely heavily on invalidation [37,40,41]. In our work,however, we concentrate on the updates of data in databases, which are by design not visible tothe Web servers. Therefore, we introduce a vertical invalidation concept, where invalidationmessages travel from database servers and Web servers to the front-end and edge cache servers aswell as JDBC database access layer caches.

8. Concluding remarks

Both response time and content freshness are essential to e-commerce applications on the Web.Many e-commerce Web applications deploy dynamic content caching solutions to serve userrequests at locations much close to users, avoiding network latency. For such Web sites, thehighest level of content freshness that can be assured is the larger value of the response time andinvalidation cycle. In this paper, we propose a freshness-driven adaptive dynamic content cachingtechnique. It monitors response time and invalidation cycle as feedback and dynamically adjustscaching policy. The technique aims at maintaining the best content freshness that a systemconfiguration can support. By considering the trade-off of invalidation cycle and response time,our technique is able to maintain the best content freshness that can be assured, which occurs atthe equilibrium point of response time and invalidation cycle. The experiments do show the ef-fectiveness and benefits of the proposed freshness-driven adaptive caching. Under the heavytraffic, the freshness-driven adaptive caching supports content freshness up to 20 times better thanthose without dynamic content caching. It also supports content freshness up to 10 times betterthan those systems that deploy dynamic content caching solutions.

References

[1] N. Bhatti, A. Bouch, A. Kuchinsky, Integrating user-perceived quality into Web server design, in: Proceedings of

the 9th World-Wide Web Conference, Amsterdam, The Netherlands, June 2000, pp. 1–16.

[2] Zona Research, http://www.zonaresearch.com/.

[3] Akamai Technology, Information available at http://www.akamai.com/html/sv/code.html.

[4] Digital Island, Ltd., Information available at http://www.digitalisland.com/.

[5] B. Krishnamurthy, C.E. Wills, Analyzing factors that influence end-to-end Web performance, in: Proceedings of

the 9th World-Wide Web Conference, Amsterdam, The Netherlands, June 2000, pp. 17–32.

[6] P. Deolasee, A. Katkar, A. Panchbudhe, K. Ramamritham, P. Shenoy, Adaptive push-pull: dissemination of

dynamic Web data, in: The Proceedings of the 10th WWW Conference, Hong Kong, China, May 2001.

[7] K. Selc�uk Candan, W.-S. Li, Q. Luo, W.-P. Hsiung, D. Agrawal, Enabling dynamic content caching for database-

driven Web sites, in: Proceedings of the 2001 ACM SIGMOD Conference, Santa Barbara, CA, USA, May 2001,

ACM.

[8] C. Mohan, Application servers: born-again TP monitors for the Web? (panel abstract), in: Proceedings of the 2001

ACM SIGMOD Conference, Santa Barbara, CA, USA, August 2001.

[9] W.-S. Li, K. Seluk Candan, W.-P. Hsiung, O. Po, D. Agrawal, Q. Luo, W.-K.W. Huang, Y. Akca, C. Yilmaz,

CachePortal: technology for accelerating database-driven e-commerce Web sites, in: Proceedings of the 2001

VLDB Conference, Roma, Italy, September 2001.

http://www.zonaresearch.com/

http://www.akamai.com/html/sv/code.html

http://www.digitalisland.com/


[10] C. Mohan, Caching technologies for Web applications, in: Proceedings of the 2001 VLDB Conference, Roma,

Italy, September 2001.

[11] M. Cherniack, M.J. Franklin, S.B. Zdonik, Data management for pervasive computing, in: Proceedings of the 2001


[12] Q. Luo, J.F. Naughton, Form-based proxy caching for database-backed Web sites, in: Proceedings of the 2001


[13] A. Ninan, P. Kulkarni, P. Shenoy, K. Ramamritham, R. Tewari, Cooperative leases: scalable consistency

maintenance in content distribution networks, in: The Proceedings of the 11th WWW Conference, Honolulu, HI,

USA, May 2002.

[14] A. Datta, K. Dutta, H.M. Thomas, D.E. VanderMeer, Suresha, K. Ramamritham, Proxy-based acceleration of

dynamically generated content on the World Wide Web: an approach and implementation, in: Proceedings of 2002

ACM SIGMOD Conference, Madison, WI, USA, June 2002.

[15] Q. Luo, S. Krishnamurthy, C. Mohan, H. Pirahesh, H. Woo, B.G. Lindsay, J.F. Naughton, Middle-tier

database caching for e-business, in: Proceedings of 2002 ACM SIGMOD Conference, Madison, Wisconsin, USA,

June 2002.

[16] K. Selcuk Candan, D. Agrawal, W.-S. Li, O. Po, W.-P. Hsiung, View invalidation for dynamic content caching

in multitiered architectures, in: Proceedings of the 28th Very Large Data Bases Conference, Hongkong, China, August

2002.

[17] W.-S. Li, W.-P. Hsiung, D.V. Kalashnikov, R. Sion, O. Po, D. Agrawal, K. Selc�uk Candan. Issues and evaluations

of caching solutions for Web application acceleration, in: Proceedings of the 28th Very Large Data Bases

Conference, Hongkong, China, August 2002.

[18] A. Datta, K. Dutta, K. Ramamritham, H. Thomas, D. VanderMeer, Dynamic content acceleration: a caching

solution to enable scalable dynamic Web page generation, in: Proceedings of the 2001 ACM SIGMOD Conference,

Santa Barbara, CA, USA, May 2001, ACM.

[19] Oracle9i data cache, http://www.oracle.com/ip/deploy/ias/caching/index.html?database_caching.html.

[20] Oracle9i Web cache, http://www.oracle.com/ip/deploy/ias/caching/index.html?web_caching.html.

[21] Persistent Software Systems Inc., http://www.dynamai.com/.

[22] J. Challenger, P. Dantzig, A. Iyengar, A scalable and highly available system for serving dynamic data at frequently

accessed Web sites, in: Proceedings of ACM/IEEE Supercomputing�98, Orlando, FL, November 1998.

[23] J. Challenger, A. Iyengar, P. Dantzig, Scalable system for consistently caching dynamic Web data, in: Proceedings

of the IEEE INFOCOM�99, New York, NY, March 1999, IEEE.

[24] E. Levy, A. Iyengar, J. Song, D. Dias, Design and performance of a Web server accelerator, in: Proceedings of the

IEEE INFOCOM�99, New York, NY, March 1999, IEEE.

[25] W.-P. Hsiung, W.-S. Li, K. Selc�uk Candan, D. Agrawal, Multi-tiered cache management for e-commerce Web

sites, in: Proceedings of Second International Workshop on Cooperative Internet Computing (CIC 2002), Hong

Kong, China, August 2002.

[26] F. Douglis, A. Haro, M. Rabinovich, HPP: HTML macro-preprocessing to support dynamic document caching,

in: Proceedings of USENIX Symposium on Internet Technologies and Systems, 1997.

[27] B. Smith, A. Acharya, T. Yang, H. Zhu, Exploiting result equivalence in caching dynamic Web content, in:

Proceedings of USENIX Symposium on Internet Technologies and Systems, 1999.

[28] A. Labrinidis, N. Roussopoulos, On the materialization of WebViews, in: Proceedings of the ACM SIGMOD

Workshop on the Web and Databases (WebDB�99), Philadelphia, PA, USA, June 1999.

[29] A. Labrinidis, N. Roussopoulos, WebView materialization, in: Proceedings of ACM SIGMOD International

Conference on Management of Data, Dallas, TX, USA, May 2000.

[30] G. Kappel, W. Retschitzegger, The TriGS active object-oriented database system––an overview, SIGMOD Record27 (3) (1998) 36–41.

[31] A. Labrinidis, N. Roussopoulos, Adaptive WebView materialization, in: Proceedings of the Fourth International

Workshop on the Web and Databases (WebDB�2001), held in conjunction with ACM SIGMOD�2001, SantaBarbara, CA, USA, May 2001.

[32] A. Heddaya, S. Mirdad, WebWave: globally load balanced fully distributed caching of hot published documents,in: Proceedings of the 1997 IEEE International Conference on Distributed Computing and Systems, 1997.

http://www.oracle.com/ip/deploy/ias/caching/index.html?database_caching.html

http://www.oracle.com/ip/deploy/ias/caching/index.html?web_caching.html

http://www.dynamai.com/


[33] A. Heddaya, S. Mirdad, D. Yates, Diffusion-based caching: WebWave, in: Proceedings of the 1997 NLANR Web

Caching Workshop, 1997.

[34] M.R. Korupolu, M. Dahlin, Coordinated placement and replacement for large-scale distributed caches, in:

Proceedings of the 1999 IEEE Workshop on Internet Applications, 1999.

[35] R. Tewari, M. Dahlin, H.M. Vin, J.S. Kay, Design considerations for distributed caching on the Internet, in:

Proceedings of the 19th International Conference on Distributed Computing Systems, 1999.

[36] R.L. Carter, M.E. Crovella, On the network impact of dynamic server selection, Computer Networks 31 (23–24)

(1999) 2529–2558.

[37] P. Rodriguez, S. Sibal, SPREAD: scalable platform for reliable and efficient automated distribution,

in: Proceedings of the 9th World-Wide Web Conference, Amsterdam, The Netherlands, June 2000, pp. 33–

49.

[38] P. Cao, C. Liu, Maintaining strong cache consistency in the world wide Web, IEEE Transactions on Computers 47

(4) (1998).

[39] J. Gwertzman, M. Seltzer, World-Wide Web cache consistency, in: Proceedings of 1996 USENIX Technical

Conference, San Diego, CA, USA, January 1996, pp. 141–151.

[40] H. Yu, L. Breslau, S. Shenker, A scalable Web cache consistency architecture, in: Proceedings of the ACM

SIGCOMM�99 Conference, Boston, MA, USA, September 1999.

[41] D. Li, P. Cao, M. Dahlin, WCIP: Web cache invalidation protocol, 2000, http://www.ietf.org/internet-drafts/draft-

danli-wrec-wcip-00.txt.

Wen-Syan Li is a Senior Research Staff Member at Computers & Communications Research Laboratories(CCRL), NEC USA Inc. He received his Ph.D. in Computer Science from Northwestern University inDecember 1995. He also holds an MBA degree. His main research interests include content delivery network,multimedia/hypermedia/document databases, WWW, E-Commerce, and information retrieval. He is leadingCachePortal project at NEC USA Venture Development Center and Content Awareness Network project atNEC CCRL in San Jose. Wen-Syan is the recipient of the first NEC USA Achievement Award for hiscontributions in technology innovation.

Oliver Po is currently a Research Engineer at Computer & Communications Research Laboratories (CCRL),NEC USA. From 1985 to 1993 he worked for IBM Taiwan as a system engineer. From 1994 to 1999 he jointIBM Toronto Lab and worked as a database developer focusing on database functions and tools design andenhancement. He received his B.S. degree at 1984. His current work involves mainly the CCRL CachePortalproject which studies and provides dynamic content caching solutions.

Wang-Pin Hsiung is a Research Associate at Computers & Communications Research Laboratories (CCRL),NEC USA Inc. He received his masters degree in Computer Science from Stanford University in 1999 andBSE from Arizona State University. His research interests are in the areas of computer network architecturesand protocols; multimedia systems; performance evaluations; and databases. He works on CachePortalproject developing static/dynamic Web content caching and also involve in the development of ContentAwareness Network.

http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt

http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt


Kasım Selcuk Candan is a tenure track assistant professor at the Department of Computer Science andEngineering at the Arizona State University. He joined the department in August 1997, after receiving hisPh.D. from the Computer Science Department at the University of Maryland at College Park. His dissertationresearch concentrated on multimedia document authoring, presentation, and retrieval in distributed collab-orative environments. He received the 1997 ACM DC Chapter award of Samuel N. Alexander Fellowship forhis Ph.D. work. His research interests include development of formal models, indexing schemes, and retrievalalgorithms for multimedia andWeb information and development of novel query optimization and processingalgorithms. He has published various articles in respected journals and conferences in related areas. Hereceived his B.S. degree, first ranked in the department, in computer science from Bilkent University in Turkeyin 1993.

Divyakant Agrawal is a Visiting Senior Research Scientist at CCRL, NEC USA, Inc. in San Jose. He receivedhis Ph.D. from SUNY, Stony Brook. His current research interests are in the area of distributed hypermediadatabases, multimedia information storage and retrieval, and Web based technologies.

Freshness-driven adaptive caching for dynamic content Web sites

Documents

Transcript of Freshness-driven adaptive caching for dynamic content Web sites