next up previous
Next: Caching Policies Up: Static Caching of Web Previous: Static Caching of Web

Introduction

The number of servers and the amount of information available in the World Wide Web have been growing exponentially in the last five years. The use of World Wide Web as an information retrieving mechanism has also become popular. As a consequence, popular Web servers have been receiving an increasing number of requests. Some servers receive up to 100 million requests daily (Netscape in mid 1996) which results in more than one request per millisecond on average. Thus, in order for a Web server to be able to respond at such a rate, it should reduce the overhead of handling the requests to a minimum.

Currently, the greatest fraction of server latency for document requests (excluding the execution of CGI-scripts) comes from disk accesses. When there is a request for a document at a Web server, the server makes one or more file system calls to open, read and close the requested file. These file system calls result in disk accesses, and when the file is not on the local disk, file transfers through a network.

Hence, it is interesting to cache the files in the main memory so as to reduce access to the local and remote disks. Indeed, RAM is much faster (by several orders of magnitude) than magnetic disks. Such an idea has already been used in some software (for example, harvest (now squid ) httpd accelerator [4]). Such a caching mechanism was called main memory caching [8] or document caching [1]. In this paper we shall refer it as server caching. Server caching might appear to have less impact on the quality of Web applications than the client caching (or proxy caching), which aims at reducing network delay by caching remote files (see [2,5]). This indeed seems to be true in traditional networks where the retrieval time of a document is dominated by transfer time due to the low-bandwidth interconnections. However, even in such a situation, a significant portion of requests of a Web server may be from local users at academic institutions or large companies. These clients are typically connected to the server through high bandwidth LANs (e.g. FDDI or ATM) so that the retrieval time is likely to be dominated by the server's latency. In the near future, with the deployment of ATM WANs, the information retrieval time is also likely to be dominated by the latency at the server.

While client caching is characterized by relatively low hit rates (varying from 20% to 40%, see [3,7,9,10,11]), the server caching, however, can achieve very high hit rates due to the particularity of Web traffic where a small number of documents of a Web server dominates the requirements of clients. It is shown in [8] by analyzing request traces of several Web servers that even a small amount of main memory (512 Kbytes) can hold a significant portion (60%) of the documents required. The same phenomenon occurs also in the two Web servers studied in the current paper.

Therefore, the analysis and the implementation of server caching can result in a significant improvement of the service of Web servers. In this paper, we propose a new caching mechanism, referred to as static caching for server caching. It has lower management overhead and higher hit rate. Under some statistical assumptions we show that static caching has the highest hit rate. We also provide empirical results obtained by trace-driven simulations, which show that static caching compares favorably to other caching policies.


next up previous
Next: Caching Policies Up: Static Caching of Web Previous: Static Caching of Web
Nicolas Niclausse
8/25/1997