Class-Oriented Page Invalidation for Caching Dynamic Web Content

Class-Oriented Page Invalidation for Caching Dynamic Web Content Huican Zhu and Tao Yang Department of Computer Science, University of California Santa Barbara, CA 93106 fhczhu, [email protected] Abstract Caching dynamic pages at a server is bene cial in reducing server resource demands and it also helps dynamic page caching at proxy sites. Previous work has used ne-grain dependence graphs among individual dynamic pages and underlying data sets to enforce result consistency. Such an approach can be cumbersome or inecient for a Web site to manage a cache in dealing with an arbitrarily large number of dynamic pages. This paper studies partitioning dynamic pages into classes based on URL patterns and the proposed scheme allows an application to specify cachability and data dependence and invoke invalidation for a class of dynamic pages. To make this scheme time-ecient with small space requirement, lazy invalidation is used to minimize slow disk accesses when URLs of dynamic pages are stored in memory with a digest format. Eager page invalidation and selective precomputing are further proposed to prefetch pages and smoothen load peaks. A data structure is developed for ecient URL class searching during lazy or eager invalidation. This paper also presents design and implementation of a caching software which integrates the above techniques, runs on top of standard Web servers, and allows Web sites to add dynamic page caching capability with minimal changes. The experimental results show that the proposed techniques can eciently handle class-oriented page invalidation and they are eective in reducing server response times with an up to seven-fold speedup for tested applications.

1 Introduction Dynamic page generation based on user pro les and request parameters has become popular at many Web sites since it can provide new types of services such as electronic commerce and personalized information presentation. There are a number of techniques proposed to speedup dynamic page delivery, for example, ecient OS support [4, 22], server clustering and load balancing [3, 9, 12, 29], content preprocessing [10], and caching dynamic content at server and proxy sites [14, 15, 24, 25]. This paper focuses on caching and invalidating dynamic pages at the server sites. Previous work on Web caching and invalidation such as [7, 13] at proxy servers mainly deals with static pages. Caching dynamic pages at server sites has several advantages: 1) it reduces the server computing resource demand. 2) it simpli es invalidation process since it is easy for a Web site to control its cache. 3) it also helps proxy-site dynamic page caching which reduces network trac. This is because, with server caching, a proxy site caching a dynamic page can use HTTP page validation model to query if the content has been changed. Time stamps of cached dynamic pages at the server site can be used to answer such queries. The work in the IBM Olympics Web server [8, 15] and in the Alexandria Digital Library system [2, 14] demonstrated the feasibility and signi cance of caching dynamic content. To maintain data consistency for cached dynamic pages, Smith et al [14] uses the standard time-to-live (TTL) technique. Vahdat et al [25] proposes the idea of intercepting le operation related system calls to monitor change of source les and the weakness is that their monitoring is limited to local le systems and it can slow down other operations. For more complicated servers which involve queries on distributed database systems, Iyengar et al. [8, 15] proposes an approach in which applications explicitly issue invalidation messages to a cache. While this approach is powerful for many Web applications, it relies on a ne-grain dependence graph which speci es dependence among individual Web pages and underlying data sets (e.g. database tables). For many sites which host an arbitrarily large number of dynamic pages (e.g. pages generated using individual user pro les), the size of such a ne-grain graph can grow enormously and enumerating and maintaining dependence in 1

such cases can be cumbersome. It can also be inecient for a Web application to instruct cache to invalidate individual pages one by one if their dependence to some data sources are unknown to the cache in advance. We propose a more comprehensive and exible caching scheme which allows users to specify coarse-grain dependence among underlying datasets and a set of dynamic pages which share common URL patterns. In this way, application programmers need not to enumerate dependence structures for all individual pages. This scheme also supports groupbased invalidation of pages sharing common patterns and these common patterns can be unknown to the cache in advance. To make the above group-based scheme ecient, we propose a number of techniques. First, since URLs of cached pages are normally stored in main memory in a digest format, problems arise when some pages matching a URL pattern need to be invalidated but such a pattern is not pre-registered to the cache. Determining what pages match such a pattern becomes virtually impossible without knowledge of page URLs. We use a lazy invalidation strategy that accumulates invalidation messages and only performs necessary page invalidation when a client access to that page is initiated. Second, to support dynamic page prefetching for increasing cache hit ratios, we further study eager page invalidation and resource based selective precomputing techniques. This selective precomputing technique balances server load along the time line and minimizes chances of server load spike. We have developed a data structure for ecient URL class searching during lazy or eager invalidation. We have designed and implemented our caching software as a middle-ware running on top of a standard Web server such as Enterprise Server and Apache server without modifying server source code, which allows Web sites to add caching capability with minimal changes (applications still need to provide cache-control speci cation and send invalidation messages). The rest of this paper is organized as follows. Section 2 introduces the concept of URL classes and describes classbased cachability and dependence speci cation, and invalidation. Section 3 discusses lazy and eager page invalidation and selective precomputing. Section 4 discusses interactions among the server, cache and applications and presents an ecient data structure for searching URL classes. Section 5 describes our simulation and experimental results. Section 6 discusses related work. Section 7 concludes the paper.

2 Page Partitioning and Cache Control Speci cation In this section, we rst discuss how dynamic pages are partitioned into groups based on their URL patterns, we then discuss how an application speci es dependence and invalidation for a group of pages.

2.1 URL Classes The syntax of page URLs provides a natual way of organizing pages into groups and is adopted as our page partitioning scheme. We use the term "URL-class" to refer to a partition. The URL of a dynamic page has three components: the content server location, a net path within this server, and possible parameters. The net path part gives the name of the application script that generates responses. The parameter part may contain two subparts. The rst subpart is the extra path information which directly follows an application name and is used in several standards such as CGI and servlet. The second subpart, following symbol `?', supplies additional parameter needed for generating responses. The net path part of page URLs are used to partition URLs based on application or directory names. Classifying pages based on directories allows an application developer to manage cachability and invalidation based on the directory hierarchy of a server. For example, a developer may place all scripts serving news whose content changes less frequently under /cgi-bin/news/ while placing all scripts serving stock-related information whose content changes frequently under /cgi-bin/stock. She then marks all scripts under /cgi-bin/stock non-cachable while scripts under /cgi-bin/news cachable. The parameter component further partitions pages generated by the same application. In addition to the parameter (name, value) pairs appearing in a URL, parameters such as client domain name, client IP address, and cookie values can also be used for page partitioning. A Web server is instructed to supply these parameters to the cache manager. A URL class is de ned by the BNF speci cation shown in Figure 1. pathinfo is the additional path information 2

< URL class > := j `?'< parameter ? condition > < parameter ? condition > := < arg > = < value > j < arg > = < value >`&'< parameter ? condition > < arg > := pathinfo j domain j IPaddress j Cookie: j < ArgID >

Figure 1: The BNF speci cation of a URL class. supplied after the application name. domain is the client domain obtained by reverse DNS lookup. IPaddress is the client IP address. cookie: is the name of a cookie. < ArgID > is the name of an argument. Some example URL classes and their meanings are:

  

/cgi-bin.

It covers all dynamic pages which are generated by scripts with /cgi-bin as their net path pre x.

/cgi-bin/news?topic=sports&country=USA. It groups pages which are generated country=USA. /cgi-bin/news may have other

with parameter topics=sports and ignored by this class.

by script /cgi-bin/news parameters, but they are

/cgi-bin/transaction? cookie:Session=1234AB. It covers all pages which are generated by /cgi-bin/transaction

and have cookie Session=1234AB.

We say that a page matches a URL class if: (1) the pathname part of the URL class is a pre x of the page path; and (2) the parameters of this page satisfy the parameter conditions of the class. A Web application can use URL classes to specify cachability, dependence and invalidation information for a group of pages. Because one URL class may be a subclass of another URL class or two URL classes may intersect, a page may match multiple URL classes and cachability and dependence speci cation for multiple URL classes may have a con ict. To resolve such a con ict, we will use a concept called minimal class which is de ned as follows. Let G be a set of URL classes, a URL class C is a minimal class of a page p with respect to G if: (1) p matches C ; (2) there does not exist any class D in G such that p matches D and D is a subclass of C . Figure 2 demonstrates such a concept. There are four URL-classes in this gure: C1 =/cgi-bin, C2=/cgi-bin/sports, C3 =/cgi-bin/sports?country=USA and C4=/cgi-bin/sports?year=1999. Page p with URL=/cgi-bin/sports?country=USA&year=1999&category=tennis matches all the four classes. But only C3 and C4 are its minimal classes. Minimal classes are used to resolve con icts in page cachability speci cation and to reduce memory requirement for maintaining (page, URL-class) relationships. Note that we did not try to construct intersections of URL classes for ensuring that each page is associated to only one URL-class. This is because, in worst case, we may need to construct 2n ? n intersections for n URL-classes. /cgi-bin/ /cgi-bin/sports

/cgi-bin/sports?country=USA

/cgi-bin/sports?year=1999

/cgi-bin/sports?country=USA&year=1999&category=tennis

Figure 2: Relationship among URL classes and the concept of minimal classes. 3

2.2 Class-Oriented Cache Control Speci cation A dynamic page may be cachable or non-cachable, and the cached content for a cachable page may be invalid if some data objects change (e.g. database tables or les). In our scheme, by default dynamic pages are non-cachable and applications explicitly register a set of URL classes which are cachable. Subclasses of cachable classes may be registered as non-cachable, and vice versa. In our current design, cachability and dependence speci cation is static and loaded at cache bootstrap time. If speci cation becomes invalid (which does not happen frequently), cache can be ushed and new speci cation can be loaded again. Figure 3 illustrates cachability and object dependence speci cation for two URL classes. The rst example speci es that pages in URL class /cgi-bin/news?topic=stock are non-cachable. The second example says that a page generated by a script with net path /cgi-bin/news is cachable and such a page should be invalidated when data object \news-table" changes. Note that here \news-table" is just an identi er. It could represent any data object, e.g. a database table. URL-Class: /cgi-bin/news?topic=stock Cachable: No

URL-Class: /cgi-bin/news Cachable: Yes Dependence: news-table

Figure 3: An example of cachability and dependence speci cation for two classes. When a page matches multiple classes and speci cations for those classes con ict, we adopt a conservative rule to resolve such a con ict: 1): A page is non-cachable if any of its minimal classes is non-cachable. (2): A page depends on an object if any of the classes it matches depends on this object. During runtime, the cache manager will receive a sequence of messages that directly or indirectly trigger invalidation of URL classes. There are three types of invalidation messages:

 Object-Change: indirect class invalidation by specifying object change.

For example:\Object-Change: weather-table". When such a message arrives, all pages matching URL classes depending on object weather-table should be invalidated.

 Invalidate-Class: direct invalidation of a URL class.

For example:\Invalidate-Class: /cgi-bin/news?topics=sports". All the pages matching the URL class given in the invalidation message should be invalidated.

 Invalidate-Page: direct invalidation of an individual page. For example: \Invalidate-Page:

/cgi-bin/txt2ps?file=README.txt".

The work in [8] uses object changes to trigger invalidation of individual pages. Our scheme expands that work by allowing group based page invalidation. And pages can be invalidated not only by specifying object change, but also by specifying a targeting URL class. One thing covered in [8] is that pages may be invalidated due to dependence between cached pages. Since the authors in [8] indicate that in practice inter-page dependence is rarely used, we have not considered inter-class dependence. If needed, inter-class dependence can be transformed into object dependence. Conceptually, our page caching and invalidation mechanism works as follows: 1) Each accessed dynamic page is stored in the cache and is identi ed by a unique page ID derived from the page URL and possibly other information such as cookies. When a request for a dynamic page arrives, the URL and the related information are extracted to construct an ID for locating a cache entry. If a cached page is found and is fresh, its content is sent to the client. If the requested page is not cached, the server invokes the application to generate a response and sends it back to the client. Meanwhile, cachability of this page is checked. If cachable, a new cache entry is created. 2) When an invalidation message arrives, it triggers invalidation of an individual page or a group of cached pages. The above procedure looks simple, however, its detailed design and implementation is complicated due to performance concerns. The following two sections present key problems we encounter and our solutions. 4

3 Page Invalidation and Precomputing Techniques 3.1 Lazy Page Invalidation First we present a problem for page invalidation caused by memory constraint in storing a large number of cached pages. A typical space-ecient way to manage a Web page cache (e.g. in the Squid proxy server [26]) is to store content in the secondary storage and only keep in memory key meta information such as page ID, last access time, and creation time. In Squid, the 16-byte MD5 digest [23] is computed as page ID for each cached URL and the space saving by using MD5 key could be tremendous because the length of a URL can be several hundred bytes. For example, in the Alexandria Digital Library [2], the length of URLs related to map retrievals can exceed 1KB. We also use the MD5 encoding method to save space. However it creates a problem for our class-based invalidation. This is because when receiving an message that triggers invalidation of a URL class, we need to compare URLs of the cached pages with this URL class. Since the inverse of an MD5 digest is not tractable, we would have to store complete URL information in disks when caching pages and retrieve them from slow disks during invalidation comparison. This process can be very expensive when a large number of pages are cached. An apparent algorithm is: When a newly generated page is rst accessed and cached, determine the URL classes it matches and record this information by setting bits in a D  C bit matrix, where D is the maximum number of documents in cache at any time and C is the maximum number of classes. When an invalidation message arrives, nd the row it corresponds and invalidate the pages with index corresponding to bit locations which are set in that row. The algorithm has several aws. First, it does not say how to match a page URL with a URL class. The matching could be time consuming considering that a URL includes both paths and parameter (name, value) pairs. This might be OK since the matching is done only once when the page is rst accessed. Second, this algorithm requires that all URL classes appearing in invalidation message are known to the cache at bootstrap time which is exactly what we want to avoid. Third, Even if such information is available, how to eeciently determine which of them the URL pattern in an invalidation message matches? Obviously, it is inecient to compare this URL pattern to them one by one. Our approach is to use lazy invalidation: invalidation is not performed until a cached page is accessed. To support lazy invalidation, we maintain a set of invalidated URL classes annotated with the latest invalidation time and call this set I-set. Lazy invalidation works as follows: 1. When an invalidation message is received, if it is of type \Invalidate-Page", the targeted page is invalidated immediately; if it is of type \Invalidate-Class", the targeted URL class is recorded in the I-set and is marked with the new invalidation time; if the invalidation message is of type \Object-Change", all the URL classes depending on this object become stale and are recorded in the I-set. Notice that only the latest invalidation time needs to be maintained for each invalidated URL class. 2. When a request for a dynamic page is received and a cache entry is found, the I-set is searched rst to verify if any of the URL classes to which the cached page matches has been invalidated after its creation time. If such a class is found, this page is stale and should be regenerated. Lazy invalidation incurs invalidation searching overhead for each page access. However, by using an ecient data structure, as to be presented in Section 4.2, such overhead is negligible.

3.2 Eager Invalidation for Page Precomputing Static page prefetching has been studied in previous research and has shown modest performance in reducing Web page delivery latency, when used together with caching [11, 17]. As dynamic pages are usually short-lived, prefetching dynamic pages is expected to be more eective in improving cache hit ratios. In fact, the IBM 1998 Olympic Web site regenerated every page when it was invalidated and as a result, a 20% cache hit ratio improvement was observed compared to no-prefetching [8]. As we show in Section 3.3, with proper optimization, dynamic page prefetching can 5

oer another advantage in averaging out the required computing capacity in a busy Web site. Since dynamic pages can be prefetched when the load is low, a server can handle more concurrent requests during its peak load. To emphasize the computation involved for page prefetching, we refer to this process as page precomputing. The accuracy of prediction on user-access patterns aects eectiveness of page precomputing. The work in [8] recomputes a page once it becomes stale, which is essentially based on the LRU principle: \if a page is accessed recently, it may be accessed soon". Following the work, we also consider that stale pages in cache are good candidates for precomputing. Lazy invalidation however prevents us from locating stale pages because the cache manager is not aware if a page is stale until this page is accessed by some client. We propose eager invalidation to remedy this problem. In addition to maintaining the I-set, we build a class-page link set which maintains pointer lists from URL classes to cached pages (we call this data structure as CP-set). The CP-set contains a set of URL classes which are frequently invalidated. When an accessed page is cached, a pointer to this page is added to URL classes with which this page matches. When a URL class in the CP-set is invalidated, all cached pages for this class are invalidated immediately and they are candidates for precomputing. Since precomputing requires knowledge of page URLs, we also store URL of each cached page in the le containing its cached content. There are three issues that need to be addressed: 1) Which URL classes should appear in the CP-set? What happens if a class appearing in an invalidation message is not in the CP-set? 2) Should a page be linked to all matched URL classes in the CP-set? 3) Is it still necessary to check the I-set for each fresh page access? Our answers are as follows: 1. Applications can pre-register URL classes which are frequently invalidated and these classes will be stored in CP-set. URL classes which specify cachability and object dependences are also maintained in the CP-set. 2. To reduce space usage, the link to a page is only added to its minimal classes with respect to the CP-set. Since classes in the CP-set are pre-registered, a subset relationship can be built in advance among these classes. 3. The system still needs to maintain the I-set and verify if a page is fresh by searching the I-set. There are two reasons. First, a class appearing in an invalidation message might not be listed in the CP-set and thus this class needs to be added to the I-set. Second, since a class in the CP-set could link a large number of cached pages, invalidation process for a class can take time. Race condition arises if during invalidation, requests for pages matching the class being invalidated arrive. Some pages which should be invalidated may be regarded as fresh and sent out. To avoid such a case, the I-set should contain all invalidated classes. Certainly freshness veri cation for most of cached pages is redundant. However as we will discuss in Section 4.2, our data structure allows fast searching of URL classes and this checkup overhead is negligible. The following is the sketch of our caching algorithm augmented with eager invalidation. 1. When a request for a dynamic page is received, if this page is not cached but is cachable, a new cache entry is created and a pointer to this entry is added to all of its minimal URL classes in the CP-set. If a fresh cache entry for this page is found, then the I-set is searched to see if any URL class matching this page exists which invalidates this page. The page is returned if it is still fresh. Otherwise it is re-generated. 2. When an invalidation message is received, if it invalidates a single page, that page is invalidated immediately; if it targets URL classes, the targeted URL classes are recorded in the I-set rst, and then all the pages pointed to by the targeted URL-classes and their subclasses in the CP-set are invalidated; 3. After invalidation, URLs of stale pages are saved in a special list for precomputing purpose. The details on precomputing will be discussed in the next subsection.

3.3 Instant Precomputing vs. Selective Precomputing In the work of [8], dynamic page precomputing is conducted whenever a page becomes stale. We call this instant precomputing and this approach is eective when the number of dynamic pages is relatively small. However since computing dynamic pages can take a fair amount of system resource, instant precomputing is not feasible for Web 6

sites hosting a large number of dynamic pages since it can create resource contention and signi cantly slow down response times for processing other user requests. Our strategy is selective precomputing: precomputing is conducted only when the system resource usage is below a certain threshold in terms of a composite load index. Let ! be the average percentage of time spent on CPU for computing a dynamic page on a machine, let x be the percentage of CPU idle time on this machine during last t seconds (we use t = 5) and y be the percentage of I/O idle time (x and y are reported by \rstat" utility), we use the following condition to check the feasibility of computing such a dynamic page on this machine: ! x1 + (1 ? !) y1  H1 where H is the threshold (we use H = 40%). This load index actually approximates the exepected stretch factor of processing such a page under current load. A threshold of 40% means that a page should not be precomputed if its processing time will be lengthened by a factor of 2:5. Currently this composite load index only covers the I/O and CPU load on machines where content-generation applications are executed. While this load index is eective for working with the Alexandria digital library server and a few other content-generation applications [30], further studies may be needed to model other resource requirement such as local network load and multiprocessing. When cachability and dependence information of an URL-class is registered, its resource demands can also be speci ed in a format of \Resource:, ". is the machine on which an application generates pages for this URL-class. The eld is the percentage of time spent on the CPU of the corresponding machine. It should be noted that in an advanced system which may have replicated servers [30], the above scheme can be extended to list multiple machines for each URL class and the system selects the best one for content regeneration. There are still two questions to be answered: How many precomputing requests are issued when system load is low? Which dynamic pages should be precomputed? We answer these two questions as follows. 1) We issue precomputing requests to the server sequentially. I.e., a new precomputing request is issued only when the previous one has nished. In this way, the system will not be ooded with precomputing requests. A tradeo here is that the idle system resources may not be utilized suciently. 2) Dynamic pages is selected as follows. When pages are invalidated, these pages are maintained in a stale page list. Pages in this list are sorted based on their last access times. Stale entries with large last-access-time values (recently accessed pages) are selected for precomputing. The philosophy used here is the same as for the LRU algorithm: pages accessed most recently are expected to be accessed soon and should be precomputed rst.

4 Caching System Design and Implementation 4.1 System Architecture Our design goal is to add caching capability to existing commodity Web servers without modifying server source code. Thus the dynamic page cache is designed and implemented as a component independent of Web servers. We have successfully integrated our cache prototype with Apache 1.3 server, Netscape Enterprise Server 3.6, and the Swala server [14], based on APIs of those servers. A Web site with dynamic page cache can be viewed as containing three key function modules: a standard Web server, a cache manager, and content-generating applications. The cache manager stores dynamic pages, invalidates cached contents when it receives invalidation messages from content-generating applications, issues requests to the server for precomputing when system resources are available, and executes a cache replacement policy when cache is full. Its data structure components include the I-set, the CP-set, cachability and dependence speci cation, and a page metainformation table for the MD5 digests of page URLs and some other bookkeeping elds. Our cache replacement policy simply uses an LRU policy and stale pages with the smallest last access time are replaced rst. Page precomputing does not trigger cache replacement because stale pages have not been explicitly deleted from the cache during invalidation and precomputing does not introduce new entries to the cache. A cache manager and a Web server interact in the following three scenarios:

 Content caching and retrieving: There are three cases: cached page is fresh, page is not cached or is stale, 7

1. req 4. resp

server

2. req 3. fresh;data

$

1. req

cache $

6. resp

2. req

server

3. noncachable

$

cache $

1. req 6. resp

5.resp

4. invoke 5. resp

App

App

4.invoke

(a). Fresh cache hit

server

2. req 3. stale 7. deposit

$

cache $

(c). Stale cache hit

(b). Non-cachable page request

Figure 4: Interaction between the server and the cache when handling client requests. $

server

1. GET url 4. deposit

cache $

2. invoke 3. resp $

1. IMS: date 4. No

server

2. IMS: date 3. No

App

cache $

(a) Server and cache interaction for processing an \IMS" request.

(b) Precomputing.

and page is non-cachable. Figure 4 illustrates the steps involved for the three cases.  Content validation: The caching system supports weak validation model proposed by HTTP/1.1 based on \Last-Modi ed" dates. Upon receiving an \If-Modi ed-Since" request from a client (or a proxy), the server passes it to the cache manager. If the corresponding page is not cached or is stale, the server invokes the application to generate a response. If the cached copy was created later than the IMS time-stamp, the cached page is retrieved to answer this client request. Otherwise, the server sends \304 Not Modi ed" response to the requesting client. Figure 4.1(a) demonstrates steps involved in the last case.  Precomputing: There are two mechanisms to invoke an application for page precomputing. 1) Let the cache manager directly invoke the application script. This solution requires an implementation that replicates all facilities in the Web server relevant to executing scripts (e.g. setting up environment variables). 2) Let the cache query the Web server and then the Web server invokes the application. Currently we use the second method since it is much simpler. To inform the Web server this request comes from the cache instead of a real client, we add an attribute in the HTTP header part of the request: From-Cache:true. The server can then check this part to determine the origin of a request. This method greatly simpli es the implementation with added overhead for script invocation. Since precomputing is invoked only when the server load is low, the overhead for this indirect application invocation is negligible. Figure 4.1(b) demonstrates the steps for precomputing.

4.2 Data Structure for Ecient Search A critical issue in implementing our caching system is to search the CP-set and I-set for page invalidation. There are two fundamental searching problems: 1) given a page URL, nd its minimal URL classes in the CP-set to set up the class-page links. 2) given a page URL, nd all URL classes in the I-set that may invalidate this page. We use a data structure composed of a trie and parameter condition classi ers for each of these URL class sets. A trie [16] is a string tree in which common pre xes are represented by tree branches, and the unique suxes are stored at the leaves. We use a trie to classify net paths and attach a parameter condition classi er, as de ned in next paragraph, to each leaf node of the trie in order to capture parameter conditions of URL classes. Our trie searching algorithm is based on our previous work which enhances processor caching performance by dynamically transferring trie nodes among small arrays, B-trees, and hash tables [1]. In designing an algorithm and data structures for searching within each parameter condition classi er, we need to address two issues: (1) The number of parameters used in a URL 8

can be far more than what have been used in the parameter conditions of URL classes. Given a page URL, how to determine what parameter names should be used for matching? (2) In locating minimal URL classes of a page, can we avoid searching superclasses of a minimal class matching this page? Given a set G of URL classes with the same net path, a parameter condition classi er for this set has three components: a parameter name index table, a sorted list of parameter condition groups, and a hash table for each parameter condition group. (1) The parameter name index table maps all parameters used in G into consecutive integers starting from 0. (2)Each group in the list of parameter condition groups is represented by a bit vector and covers the URL classes which use the same parameter names. The i-th bit in the bit vector is set if the corresponding parameter (derived from the parameter name index table) appears in this group of URL classes. (3) The hash table for each parameter condition group further dierentiates URL classes based on parameter values. Figure 5 illustrates our data structure for a CP-set with six URL classes: /cgi-bin/news, /cgi-bin/sports/tennis, /cgi-bin/sports/soccer?events=world-cup, /cgi-bin/sports/soccer?country=Italy, /cgi-bin/sports/soccer?country=Germany, /cgi-bin/sports/soccer?country=Italy&events=League-match.

There is a parameter classi er attached to node \soccer" because there are four URL classes with the same net path \/cgi-bin/sports/soccer". This classi er uses two parameters: \country" and \events" which are mapped to bit location 0 and 1 respectively. There are three parameter groups in the classi er. The rst group uses both \country" and \event' parameters. The second group uses parameter \event" only, and the third group uses parameter \country" only. /cgi-bin

Trie for pathnames

news sports

/cgi-bin/news

tennis soccer

/cgi-bin/sports/tennis param index Classfier for parameters of /cgi-bin/sports/soccer

0 country 1 events hash tables

paramater condition groups 1 1

1 0

0 1

events=world-cup

country=Italy&events=League-match country=Italy country=Germany

Figure 5: Data structure for a CP-set with six URL classes. We describe how to eciently nd the minimal classes of a given page p. First, the longest pre x in the trie which corresponds to a URL class is identi ed for the page path of p. If that URL class does not have parameters, it is the only minimal class of p. Otherwise, a classi er is located from a leaf node of the trie. By inspecting the parameter name index table, useful parameters are selected. The next step is to search suitable classes by scanning parameter condition groups. This scanning is conducted in a decreasing order of the numerical values of the bit vectors. The reason for this order is that if a URL class x is a subclass of class y, then the bit vector for x's group is larger than the bit vector for y's group and will be checked rst. Thus once a URL class matching p is found from a group G , searching the remaining groups with bit vectors subsumed by G 's bit vector can be avoided. For each selected group, the relevant parameter values are extracted based on the bit vector and the corresponding hash table is searched. We use an example to illustrate how to search for minimal classes in Figure 5. Given URL p=/cgi-bin/sports/soccer?country=Italy&events=League-match&year=1999, we rst follow the branches of the 9

trie to locate the classi er for net path /cgi-bin/sports/soccer. From the parameter index table, we know that the values of two parameters \country" and \event' are useful. The rst bit vector to check is (1; 1). And we do a hash table lookup for parameter country=Italy&event=world-cup, which successfully nds a URL class called U with condition country=Italy&events=League-match. The next bit vector to check is (1; 0). Since (1; 0) is subsumed by (1; 1), we do not need to do a hash lookup for this vector because even if the hash lookup is successful, the returned URL class must be U 's superclass which is not a minimal class of p. With the same reason, we skip the group with vector (0; 1). Therefore, U is the only minimal URL class of p. To nd all URL classes in the I-set that match a given page, we need to search all hash groups in a condition classi er. For locating minimal classes, even if we can skip a number of groups in most cases, in the worst case we may still need to scan all groups within the classi er. However, we do not expect searching all groups creates performance concerns because although the number of possible values for parameters could be unbounded, in practice the number of parameter names and their possible combinations used for de ning URL classes is expected to be small. Therefore, the size of a parameter condition group list is not large for searching. Our test result in Section 5.4 veri es eciency of our data structure.

5 Experimental Results Currently our dynamic content caching system runs on top of Netscape Enterprise Server 3.6, Apache server 1.3, and the Swala Web server [14]. The cache manager is based on Swala cache code and uses a mixed multi-threading and event-driven model. In this section, we illustrate the use of our system in three applications: on-line forum, customized news service, and on-line auction and show performance of the proposed techniques. We also study eectiveness of our data structure by examining searching overhead. In the experiments, we run a Swala Web server, a cache manager, and the involved applications on the same machine. All the tests were done on a 128MB memory 248MHz Sun Ultra-30 machine running Solaris 2.6. Client requests are generated from machines within a local area network following some real traces or client behavior models. During experiments, we compare the response time and cache hit ratios for the following four strategies: (1) no dynamic page caching; (2) caching with lazy invalidation. (3) caching with eager invalidation and instant precomputing; (4) caching with eager invalidation and selective precomputing. Page precomputing is invoked when the host CPU utilization and I/O bandwidth consumption over a certain period ( 5 seconds in our tests) is below a threshold (40%).

5.1 Online Forums Web site www.melissavirus.com provides an on-line discussion forum on the notorious Melissa Virus after its enormous destruction to computers worldwide. By observing how this Web site responds to client requests, we have developed an application to mimic the design and behavior of this Web site. We have also obtained an access log of this Web site and use it to evaluate performance of our system. Mainly there are three types of dynamic pages generated at this Web site: page /default.asp is the front page and shows a summary of major news from CNN and others on this virus; page /forumchat.asp displays a summary of all messages posted to the online forum; and each individual page /chat/default.asp?M=msg-id shows the content of a particular message together with a summary of all posted messages. For cachability, we specify the following three cachable classes: /default.asp, /forumchat.asp, and /chat/default.asp. The cached front page needs to be invalidated only when new information on this virus is added. The forum summary page and individual message pages are changed frequently because once a new message is posted to the discussion forum, the content of these pages changes. We use URL class /chat/default.asp to invalidate message pages. Our test uses a real trace collected on April 3, 1999 from www.melissavirus.com. This one-day trace has a total of 53508 requests, among which there are 4612 dynamic requests. The rest of the requests are mainly for fetching embedded images. From this trace we observed that the number of front page changes is 29 while the number of front page accesses is 3063; the number of new messages posted is 106 while the number of message accesses is 1413. 10

Our client simulator forks a new thread for each request and it issues requests to the server by following the time intervals recorded in the access log. The dynamic pages are generated by a CPU intensive script with an average processing time of 0.5 second for each request. Table 1 reports the number of fresh cached pages accessed, fresh cache hit ratio and the average response time for the four dierent strategies based on the average of three runs. As this table shows, dynamic content caching leads to a cache hit ratio of 68%. Eager invalidation with precomputing further increases cache hit ratio by 20% in the instant precomputing case and 16% in the selective precomputing case. In terms of average response times, the speedup is 3.5 comparing the no-caching case with selective precomputing. Notice that instant precomputing actually leads to higher cache hit ratio, however, Table 1 shows that instant precomputing results in higher response time because it competes resources with other request serving activities during load peaks and slows down those activities. Strategy

Number of Fresh cache Avg CGI Avg HTML # fresh cache hits hit ratio resp time resp time No caching N/A N/A 1375 msec 67 msec Caching, lazy invalidation 3148 68% 557 msec 58 msec Eager inval., instant precomp. 4047 88% 505 msec 53 msec Eager inval., selective precomp. 3874 84% 391 msec 45 msec Table 1: Test results for the Melissa Virus trace.

5.2 Customized News Service At many Web sites such as www.MyCNN.com, online pages can be customized by clients to suit their own interests. We wrote a simple customized news application which classi es headline news from each country based on topics such as weather, politics, and sports, and sends dynamic pages to users based on their pro les. Dynamic pages are generated using a script: /cgi-bin/news with two arguments: topic=some topic and country=some country. Initially, we specify that the URL class /cgi-bin/news is cachable but the URL class /cgi-bin/news?topics=stock quote is noncachable. When the content related to a topic (such as sports) changes, all pages which contain related headlines (e.g. URL class: /cgi-bin/news?topic=sports), should be invalidated. In our experiment, we assume that there are 10 dierent news topics and each topic has 100 dierent countries to choose from. We also assume that at every 30 second interval, contents related to an average of three topics may change, which means that about 30% of cached dynamic pages need to be invalidated every 30 seconds. We assume the probability that a topic change contents follows Zipf distribution, a distribution which has been observed in many human behaviors and Internet related scenarios [5, 6]. To model client access patterns, we have followed an approach studied in [19] which uses state transition graphs to model client behaviors. Figure 6 depicts our model on how clients behave in the evaluation. A client moves between two states: SLEEP and STAY. A client moves from SLEEP state to STAY state by issuing a new request. During the STAY state, the client automatically reloads the same page every 30 seconds. With a probability p, a client may manually refresh the page after waiting a period less than 30 seconds. When the client completes the action in the STAY state, he/she moves to SLEEP state. The test assumes that the average stay time is 120 seconds, the average sleep time is 60 seconds, and the probability of manual refresh is 30%. The above client behaviors mimic the access patterns at Web sites such as www.MyCNN.com, which generates customized news pages with a meta eld to enable automatic page reloading in every \num seconds". The script simulating customized news generation spends an average of 500 milliseconds to generate a response. For each one hour test period, each client retrieves about 100 pages. Table 2 shows the average response times of dynamic requests seen by clients and the cache hit ratios seen by the server. under the four dierent caching and precomputing strategies. The result shows that eager invalidation with selective precomputing is very eective and can have a response time speedup of 5.5, 2.1, and 1.5 compared to the no caching case, lazy invalidation, and instant precomputing respectively when there are about 160 concurrent client 11

manual refresh state expires

STAY

SLEEP state expires

auto refresh

Figure 6: State transition diagram of clients retrieving customized news pages. accesses. We also observe that more performance improvement is obtained when we increase the number of concurrent client accesses. Number of clients

40 60 80 160 resp time hit ratio resp time hit ratio resp time hit ratio resp time hit ratio No caching 840 N/A 1130 N/A 1570 N/A 8340 N/A Caching, lazy invalidation 570 31% 850 35% 1100 42% 3250 58% Eager inval., instant precomp. 350 83% 720 80% 980 78% 2270 84% Eager inval., selective precomp. 320 75% 590 77% 740 77% 1520 80%

Table 2: Average response time in milliseconds and fresh cache hit ratios for a news service. To study impact of precomputing on server CPU load, we also recorded server CPU utilization for every 12 seconds during the one hour test period for each strategy. Figure 7(a) shows server CPU utilization when serving 60 clients and using caching only scheme and Figure 7(b) is for selective computing. We consider that server load is low when the CPU utilization is below 30% while server load is high when utilization is above 90%. It can be observed that server CPU utilization exceeds high load water-mark more frequently in Figure 7(a) than in Figure 7(b). This shows that selective precomputing can not only increase cache hit ratio but also smoothen burstiness of server resource demands by averaging out server loads. To further validate this statement, in Figure 7(c), we sort the probing points in an increasing order of the corresponding CPU utilization and mark the percentage of points below the low load water-mark and above the high load water-mark. The results show that the percentage of points that exceed high server load water-marks reduces from 16% to 10% by using selective precomputing. Without precomputing, 40% of time the server is under utilization while selective precomputing reduces this number to 22%.

5.3 Online Auction Typically, pages at an auction site such as eBay can be categorized as: 1) main page: It lists all the item categories and the number of bidding items in each category. 2) category pages: For each category, there is a page(or possibly broken into multiple pages) listing all the bidding items in that category, and their current bidding status(end time, current price, etc). 3) bid form: This page is for users to give new prices for an item. When a user bids on an item, price change for that item should be re ected in its category page. I.e. the category page containing this item should be invalidated if cached. 4) item-add form: This page is for users to add new items. When a new item is added, the main page as well as the category page containing this item may also change. According to data published in the eBay web site (www.ebay.com), eBay currently receives 50 million hits per day, among which about 800,000 are bidding requests and 250,000 are new item posting requests. If we do not count the requests for embedded images, then among all the requests for eBay pages, about 10% requests are for bidding, and 3% requests are for adding new items. To model user bidding patterns, We also collected the numbers of daily bids on featured items at eBay from May 28, 1999 to June 8, 1999 and have observed that the numbers of bids on these items 12

100 high load watermark

90 selective precomp caching, no precomp

80

16%

70

80 60 40 20 0

0

50

100

150 Time

200

250

300

CPU utilization

100 Percentage of CPU utilization

Percentage of CPU utilization

100

80 60

10%

60

50

40

30

40

low load watermark 20

20

22% 10

0

0

50

100

(a)

150 Time

200

250

300

0

40%

0

50

(b)

100 150 200 Load probing points sorted by increasing CPU utilization

250

300

(c)

Figure 7: Comparison of server CPU utilization when accessed by 60 clients. (a)CPU utilization for the caching-only case. (b) CPU utilization for selective precomputing. (c)Sorted CPU utilization for both cases. ordered from \hot" to \cold" (i.e. receiving least bids) also follow Zipf distribution [31]. Figure 8(a) shows a typical distribution on June 1. 1999, which follows Zipf distribution. The X axis is the item ranks in a logarithmic scale sorted in a decreasing order of the number of bids received. The Y axis is the number of bits received in a logarithmic scale. 0.1

5

0.1 4.8

cat 1

main

4.6

Logarithm of number of bids

cat 2

0.9 0.5

4.4

0.25 4.2

inval

0.25

0.25 0.1 inval

3.8

3.6

3.4

add new item 0

0.5

1

1.5

2

2.5 3 Logarithm of ranks

3.5

4

4.5

(a)

0.25

bid 0.5

0.5

5

0.3

inval

4

(b)

Figure 8: (a) Log-Log distribution of numbers of user bids on featured items at eBay. (b) User transition patterns during our on-line auction test and content dependence of dynamic pages. We have developed a prototype application which models activities at on-line auction sites. In our setting, main page is generated by script /main.cgi and category pages are generated by script /items.cgi with category name as an argument. These pages are cachable. When the bidding price of an item changes, the dynamic page for the corresponding category is invalidated. When a new item is added, both the main front page and the corresponding category page are invalidated. Figure 8(b) illustrates possible user browsing movement among these pages and invalidation scenarios. The numbers attached to transition edges are the assumed transition probabilities in our experiments. These data give us close to 10% requests for bidding and 3% requests for adding new items among all the page access requests. This setting is consistent to the statistics of eBay mentioned above. We use mSQL database system (available at www.hughes.com.au) as the bidding management backend. The database is initialized with 1000 bidding items belonging to 100 categories before each test. Our request issuing program was designed based on SURGE [5]. As is observed at eBay, Zipf distribution is used in our tests to model user bidding patterns on listed items. 13

Table 3 lists the test results we obtained when 40, 80, and 160 concurrent clients were used to drive the test and each test lasts 2 hours. As average response time for static les does not change much, only results for dynamic requests are displayed. Table 3 shows that eager invalidation with selective precomputing can result in 84% fresh cache hit ratio, and yields a 7.6-fold response time speedup compared to the no-caching case and 1.9-fold compared to lazy invalidation. Improvement increases substantially as more concurrent clients access the server. # clients

40 80 160 avg. resp hit ratio avg. resp hit ratio avg. resp hit ratio No caching 810 N/A 1230 N/A 9860 N/A Caching, lazy inval. 220 67% 310 65% 2450 70% Caching, selective precomp. 170 82% 260 82% 1280 84%

Table 3: Request response times in milliseconds and hit ratios in on-line auction.

5.4 Overhead for Searching URL Classes Lazy invalidation avoids slow disk accesses in invalidating pages. The time saving is obvious when invalidating a large number of pages. For example, in our 248MHz Ultra-30 with Ultra-Wide SCSI disk, it takes over 2 seconds to search 1000 disk les and 1836 seconds to search 1000,000 les if URL of each page is saved at the beginning of the page content le. For large numbers of pages, search cost is also substantial even if all cached URL information is packed in one le. Eager invalidation is an improvement to lazy invalidation by enabling early page invalidation for prefetching without involving disk access overhead. Our invalidation scheme incurs overhead when searching through the CP-set and I-set for matching and minimal URL classes for a page. By using the data structure proposed in Section 4.2, for the above three application cases we studied, URL class searching overhead per request is less than or about 0.1 millisecond, which is very small. Because there are few URL classes involved in the tested applications, we have conducted more experiments to study how our data structure performs in the presence of large numbers of URL classes. Trie searching has already been shown very fast [1], therefore, we only examine the time spent in a parameter condition classi er for locating matching URL classes. Table 4 shows the measured results for dierent test settings. The rst row is the number of parameter groups in a classi er. The second row is the average number of URL classes covered by each group. The third row is classi er searching cost per request. We have only tested up to 100 parameter condition groups per classi er because in practice the number of parameter names used in an application for invalidation is usually limited. This table shows that the proposed data structure results in very fast URL class searching. And the search time is fairly independent of the number of URL classes in each parameter condition group, which is an advantage of our data structure. The 0.126 millisecond overhead for the 1 parameter group and 10 classes per group case actually represents the overhead for our customized news service test case where 10 URL classes and 1 parameter group were used in invalidation. There are two points we want to emphasize. 1) The overhead we measured in the tests is the overhead for locating matching classes for a page, which requires linearly scanning all parameter groups and performing a hash lookup for each matching group. The overhead for locating minimal URL classes for a page would be less since searching of some groups can be avoided. 2) Our data structure is necessary to achieve low-overhead searching. The last row of Table 4 shows search costs when linearly comparing a given page to all URL classes instead of using our data structure. For a large number of URL classes, the cost can exceed 624 milliseconds. # param. condition groups/classi er 1 10 100 # URL classes per group 10 100 1000 10 100 1000 10 100 1000 Search overhead per request 0.126 0.127 0.126 0.179 0.177 0.174 0.235 0.224 0.225 Cost of linear comparison per request 0.17 0.562 4.564 0.645 5.4 59.0 5.4 58.7 624.2

Table 4: Overhead in milliseconds for searching URL classes in a parameter condition classi er. 14

6 Related work In this paper, we discussed techniques for dynamic content caching. To minimize impact of dynamic request processing to Web servers, there are two common strategies: (1) Reducing application launch overhead; (2) Caching. The original method for dynamic content generation is by the CGI mechanism. This mechanism incurs high execution overhead because it requires forking a new process for each request. FastCGI [20] was proposed to remedy the fork/exec problem with minimal requirement of application changes. IO-Lite [22] attacks such a problem by reducing the number of buer copying between applications and the Web server. Many Web servers, such as Netscape Enterprise Server and Microsoft Internet Server, minimize such overhead by providing APIs for bundling user applications into server address space. For applications involving content customizations and database accesses, It is the processing time that contributes to most of user perceived access delay. From a server point of view, such processing time can be reduced by caching generated contents for answering future requests. Web caching is essential in providing fast response to user requests. a lot of research has been performed for improving caching performance or ensuring content consistency with origin servers [7, 8, 10, 17, 18, 27, 28]. In principle, clients and proxies can only cache static contents and the methods they use for ensuring content consistency are only applicable to static contents. This is because: (1) dynamic contents are usually valid only once(for example, an access counter) or only valid for a short period (for example, score boards); (2) a server can easily verify if a static page cached by clients or proxies has been modi ed, but it cannot do that for a dynamic page without re-invoking the corresponding application to generate a response; (3) the accurateness of some dynamic contents (for example, bidding prices) are so vital that an out-of-date dynamic page may have dramatic results. But some dynamic contents, for example, news pages or bidding price pages, can be cached by Web servers. This is because (1): Though the page contents may change at any time, they are usually stable for some period. (2): The cached contents can be invalidated by the underlying applications immediately and eciently if the contents need to be updated, due to the (physical) closeness between the servers and the applications. Despite its importance, study on dynamic content caching by Web servers [8, 10, 14, 15, 25] has been very limited as compared to static content caching. There are two major reasons: it is dicult to collect traces because dynamic contents usually involve sensitive or personal data, and it is dicult to replay dynamic content traces because replaying requires setting up application execution environments, such as necessary database backends. The methods proposed in the literature for servers to invalidate cached contents are:

 by specifying a fresh period for dynamic contents [14]. This method is only valid for contents (e.g. Alta Vista

search results) which can tolerate staleness. Note that, pages that can be invalidated by this method without worrying about correctness can also be cached by clients and proxies for a short period.

 by intercepting le operation related system calls [25]. This method monitors change to underlying les and

invalidate related dynamic contents accordingly. Note that this method is only applicable to dynamic contents which only depend on resources (programs and data) stored on the local le systems. For contents which depend on access to remote database or les stored on distributed le systems, this method is not applicable.

 by specifying dependence between pages and underlying resources, and issuing explicit invalidation messages when some resources change [8]. Invalidated pages are precomputed immediately.

Our work is closely related to [8]. But instead of specifying dependence information for individual pages, we study how to partition pages into classes and how to partially invalidate pages in a URL class. The cache-server-application con guration we use, is also dierent from that in [8]. In [8], the Web server does not talk to the cacher directly. Every request will go through the application even if it results in a cache hit. Considering that a close to 100% cache hit ratio was observed at the 1998 Winter Olympic Games Web site, we believe that our con guration, which does not involve application at all for a cache hit, is better. 15

Another dierence between our work and [8] is that we assume computation power is nite and we do precomputing only when computation power is available. Similar techniques to precomputing are static le prefetching which may happen between proxies and servers [17] or between clients and proxies [11]. Precomputing can be viewed as a technique orthogonal to server clustering with load balancing [3, 9, 21, 30] in that server clustering distribute workloads spatially while precomputing tries to distribute load temporally. Recent invalidation techniques for Web caching use multicast networks [18, 27, 28] for eciently enforcing consistency over the Internet. Their work does not explicitly address dynamic content invalidation Our proposed work can be leveraged by these techniques for distributed dynamic content caching.

7 Concluding Remarks This paper proposes a group-based page invalidation scheme using URL classes. The scheme enables ecient and

exible content caching for Web sites hosting an arbitrarily large number of dynamic pages and avoids ne-grain level cache manipulation. Lazy invalidation avoids slow disk accesses while eager invalidation further facilitates dynamic page precomputing that averages out server load peaks and increases cache hit ratios. The proposed data structure using tries and parameter condition classi ers allows for fast searching of URL classes. Our caching system integrates the proposed techniques and is implemented on top of standard Web servers without modifying server source code. Even though the scripts that generate dynamic content in our experiments are not so resource intensive ( cost is around 500 milliseconds or less per request), we have still observed substantial response time reduction, especially when the number of concurrent client accesses increases. For example, response times decrease from 8.34 to 1.52 seconds (i.e. a 5.5-fold speeup) in a news test case and from 9.86 to 1.28 seconds (i.e. a 7.6-fold speedup) in an auction case, which is substantial even considering Internet delay. We expect more improvements can be observed if our techniques are properly integrated with proxy caching or if page generation requires more intensive resources such as digital libraries. Instant precomputing has better caching hit ratios than selective precomputing, however, it worsens resource contention during load peaks and leads to higher response times. Thus load smoothening bene t of dynamic page prefetching outweighs caching bene t and eager invalidation with selective precomputing strikes a necessary balance for both smoothened server load and higher cache hit ratios.

References [1] A. Acharya, H. Zhu, and K. Shen. Adaptive Algorithms for Cache-ecient Trie Search. In ACM and SIAM Workshop on Algorithm Engineering and Experimentation, Jan. 1999. [2] D. Andresen and et al. The WWW Prototype of the Alexandria Digital Library. In Proceedings of ISDL'95: International Symposium on Digital Libraries, Aug. 1995. Revised version appeared in IEEE Computer, 1996, No.5. [3] D. Andresen, T. Yang, V. Holmedahl, and O. Ibarra. SWEB: Towards a Scalable WWW Server on MultiComputers. In Proceedings of the IEEE International Symposium on Parallel Processing, pages 850{856, Apr. 1996. [4] G. Banga and J. Mogul. Scalable Kernel performance for Internet servers under realistic load. In Proceedings of USENIX Annual Technical Conference, 1998. [5] P. Barford and M. E. Crovella. Generating Representative Web Workloads for Network and Server Performance Evaluation. In Proc. of ACM SIGMETRICS'98, 1998. [6] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. Shenker. Web Caching and Zipf-like Distributions: Evidence and Implications. In Proceedings of IEEE Infocom'99, Mar. 1999. [7] P. Cao and S. Irani. Cost-Aware WWW Proxy Caching Algorithms. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Dec. 1997. [8] J. Challenger, A. Iyengar, and P. Dantzig. A Scalable system for Consistently Caching Dynamic Web Data. In Proceedings of the IEEE INFOCOM'99, Mar. 1999. [9] M. Colajanni, P. S. Yu, and D. M. Dias. Analysis of Task Assignment Policies in Scalable Distributed Web-Server Systems. IEEE Transactions on Parallel and Distributed Systems, pages 585{598, June 1998. [10] F. Douglis, A. Haro, and M. Rabinovich. HPP: HTML Macro-Preprocessing to Support Dynamic Document Caching. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Dec. 1997.

16

[11] L. Fan, P. Cao, and Q. Jacobson. Web Prefetching Between Low-Bandwidth Clients and Proxies: Potential and Performance. In Proc. of ACM SIGMETRICS'99, May 1999. [12] A. Fox, S. Gribble, Y. Chawathe, E.A.Brewer, and P. Gauthier. Cluster-based scalable network services. In Proceedings of the Sixteenth ACM Symposium on Operating System Principles, Oct. 1997. [13] J. Gwertzman and M. Seltzer. World-Wide Web Cache Consistency. In Proceedings of 1996 USENIX Annual Technical Conference, Jan. 1996. [14] V. Holmedahl, B. Smith, and T. Yang. Cooperative Caching of Dynamic Content on a Distributed Web Server. In Procecedings of the Seventh IEEE International Symposium on High Performance Distributed Computing, July 1998. [15] A. Iyengar and J. Challenger. Improving Web Server Performance by Caching Dynamic Data. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Dec. 1997. [16] D. Knuth. The Art of Computer Programming. volume 3: Sorting and Searching. Addison-Wesley, 1973. [17] T. M. Kroeger, D. D. Long, and J. C. Mogul. Exploring the Bounds of Web Latency Reduction from Caching and Prefetching. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Dec. 1997. [18] D. Li and D. R. Cheriton. Scalable web caching of frequently updated objects using reliable multicast. In Proceedings of the Second USENIX Symposium on Internet Technologies and Systems, pages 92{103, Oct. 1999. [19] D. Menasce, V. Almeida, R. Fonseca, and M. A. Mendes. Resource Management Policies for E-Commerce Servers. In Second Workshop on Internet Server Performance, May 1999. [20] OpenMarket. Fast CGI. http://www.fastcgi.com/. [21] V. S. Pai, M. Aron, G. Banga, M. Svendsen, P. Druschel, W. Zwaenepoel, and E. Nahum. Locality-Aware Request Distribution in Cluster-based Network Service. In Proceedings of ASPLOS-VIII, Oct. 1998. [22] V. S. Pai, P. Druschel, and W. Zwaenepoel. IO-Lite: A Uni ed I/O Buering and Caching System. In Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI'99),, Feb. 1999. [23] R. Rivest. The MD5 Message-Digest Algorithm. http://www.ietf.org/rfc/rfc1321.txt, Apr. 1992. [24] B. Smith, A. Acharya, T. Yang, and H. Zhu. Exploiting Result Equivalence in Caching Dynamic Web Content. In Proceedings of Second USENIX Symposium on Internet Technologies and Systems(USITS99), Oct. 1999. [25] A. Vahdat and T. Anderson. Transparent Result Caching. In Proc. of 1998 USENIX Technical Conference, 1998. [26] D. Wessels. Squid Internet Object Cache. http://squid.nlanr.net, 1995. [27] J. Yin, L. Alvisi, M. Dahlin, and C. Lin. Hierarchical Cache Consistency in WAN. In Proceedings of the Second USENIX Symposium on Internet Technologies and Systems, Oct. 1999. [28] H. Yu and L. Breslau. A Scalable Web Cache Consistency Architecture. In Proc. of ACM SIGCOMM'99, Sept. 1999. [29] H. Zhu, B. Smith, and T. Yang. Scheduling Optimization for Resource-Intensive Web Requests on Server Clusters. In the Proceedings of the Eleventh Annual ACM Symposium on Parallel Algorithms and Architectures (SPAA'99), June 1999. [30] H. Zhu, T. Yang, Q. Zheng, D. Watson, O. H. Ibarra, and T. Smith. Adaptive load sharing for clustered digital library servers. Procecedings of the Seventh High Performance Distributed Computing, July 1998. [31] G. K. Zipf. Human Behavior and the Principle of Least Eort. Addison-Wesley, Cambridge, MA, 1949.

17