Load Balancing of DNS-Based Distributed Web Server Systems with Page Caching

Load Balancing of DNS-Based Distributed Web Server Systems with Page Caching Zhong Xu Rong Huang Laxmi N. Bhuyan Department of Computer Science & Engineering University of California, Riverside, CA 9252, USA {zhong, rongh, bhuyan}@cs.ucr.edu Abstract The explosion of WWW traffic has triggered great interest in distributed web server systems. Among various distributed web server architectures, the DNS-based distributed system is a promising solution in terms of performance, scalability and availability. DNS(Domain Name Server) name caching has significant effects on the load balance of distributed web server systems, due to the traffic skewness it causes. Also, there is page caching along whole paths between clients and web servers, and page caching schemes could affect the system load balancing a lot. In this paper, we examine various caching issues, including the load balancing algorithms of the DNS, the locations of caches, and the page caching policies, for the DNS-based web server system. We use stochastic processes to model the web traffic, and compare the load balance performance of these algorithms and policies based on simulation results. We found that, the DNS load balancing algorithm, which takes into account both client domain information and server load information, could yield best load balance performance among various algorithms, and a serverside cache with the policy which only caches popular web pages could significantly improve both the cache hit ratio and the load balance.. Introduction As a result of the rapid growth in Internet web traffic, more and more web sites replicate information across independent or coordinated servers. Among various solutions, the distributed web server system is the most promising one [8]. Due to enhanced capability, distributed processing and information replication, the cluster of web servers could significantly increase the processing throughput of the system and reduce the response delay. There are mainly two kinds of architectures for distributed web server systems - dispatcher-based systems [7][3] and DNS-based systems. In a typical dispatcher-based system, http requests from clients must reach a hardware point called dispatcher, which may be a special switch (IP-dispatcher) or a front-end at the distributed web server. The dispatcher redirects each request to one of the web servers by either modifying the destination IP address contained in the packet header or establishing an additional connection between the dispatcher and the web server. The selected web server sends response to the http request to the client directly or indirectly. Although the dispatcher-based architecture could yield excellent performance of load balancing, the dispatcher may become the bottleneck and restrict the scalability of the system [6]. Fortunately, the DNS-based distributed web server system doesn t have such a bottleneck problem. This kind of distributed web server system, which consists of multiple replicated web servers and a cluster DNS (Domain Name Server), is illustrated in Figure. The DNS translates the logical site name into the IP address of one of the web servers, and clients communicate with web servers directly. This architecture can improve the system scalability, and is suitable for geographically distributed web server systems. However, the DNS-based system has a problem with load balancing. Since intermediate name servers would supply cached name-to-address mappings to address resolving requests, clients in the domains behind the same name server would be mapped to the same web server. If clients are not uniformly distributed, name caching would cause skewed traffic and load imbalance among web servers. The limited DNS control and the highly skewed traffic require the DNS to apply a more sophisticated DNS load balancing algorithm in order to avoid the overload of web servers. M. Colajanni et al. considered DNS name caching, and compared a number of load balancing algorithms for DNSbased distributed web server systems [8]. They concluded that taking advantage of both domain information and web server load information would lead to best performance among various strategies. However, they did not consider the effects of page caching on the performance of web server systems. Besides name caching, there is also page Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

Cache Local NS/Gateway Clients Server side Gateway Address Requests Network DNS Web Servers Distributed Web Server System Clients Cache Page Requests Cache Local NS/Gateway Figure. DNS-based Distributed Web Server System caching in the Internet. Page caching takes advantage of reference locality, and could reduce network traffic and possibly reduce latency. Moreover, it is possible to further improve the performance of load balancing in a DNS-based distributed web server system by utilizing suitable page caching schemes. In this paper, we investigate the effects of some page caching strategies on the load balancing of DNS-based systems. In general, page caching could reduce the traffic load of web server systems. But it is unlikely that simple page caching could greatly improve the load balance, since statistically hit ratios for requests from different clients should be roughly equal. There are two ways to further improve the page cache performance. One is to find a better caching policy, and the other is to use prefetching. Prefetching is a technique that browsers/proxies/caches/ servers predict user preference and request pages before the user actually requests those pages. However, straightforward prefetching approaches may have serious negative performance effects on networks, such as severe traffic bursties and queueing effects [9]. Moreover, there are several negative factors that may affect log-based prefetching and could cause wrong prediction [][4]. Due to these difficulties in prefetching, there is an interest in taking advantage of page access statistical information instead of page access patterns [6]. Studies [4][5] show that page accesses are non-uniformly distributed. It is obvious that caching frequently accessed pages is more efficient than caching seldom accessed pages. Thus we can consider the page popularity when making caching decisionproce, and only cache frequently accessed pages (also called hot pages). In the following sections, we will study the impacts of this caching policy on the load balancing performance of the DNS-based distributed web server system. In this paper, we examine and evaluate various caching strategies, including DNS load balancing algorithms, cache locations, and page caching policies, for the DNS-based web server system. We use stochastic processes to model the web traffic, and compare the load balance performance of these algorithms and policies based on simulation results. The rest of this paper is organized as follows. In section 2, we introduce some load balancing algorithms used by the DNS and several caching policies in our simulation. In section 3, simulation models, including client distribution model, file size distribution model, file access model and traffic models, are discussed in detail. In section 4, we first introduce the performance metrics used in this paper, and then evaluate the effects of DNS load balancing algorithms, page cache locations, and page caching policies on the load balancing performance of the system. Finally, conclusions and future work are given in section 5. 2. Load Balancing Algorithms and Caching Policies 2.. Load Balancing Algorithms For a DNS-based distributed web server system, the DNS assigns one of IP addresses of web servers to each address resolving request. The straightforward way to determine which web server to be assigned is Round Robin (RR). However, the name-to-address mapping will be cached in name servers along the path from the DNS to the client, and later address requests reaching these name servers will be resolved with cached addresses. The later address request can be served by the DNS only when the name-to-address mapping in the cache has been invalidated due to replacement or expired TTL (Time-To-Live). Therefore, because of name caching and non-uniform distribution of clients, RR generally doesn t work well in terms of load balancing. In order to further alleviate the load imbalance caused by name caching, some advanced DNS load balancing algorithms use additional system state information to determine a better web server when the DNS resolves the address request. In general, there are two kinds of system state information - client domain information and server load information, and we can classify the DNS load balancing algorithms into three categories - using domain information only, using server load information only, and using both domain and server load information [8]. In addition to the selection of the server, we can also adjust the TTL value dynamically [6]. However, in this paper, we only use the method of server selection, and will not compare the efficiency of these two methods. Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

Domain information is the statistical information of address requests and page requests coming from each client domain. Two-Tier-Round-Robin (RR2) is one load balancing algorithm which takes into account client domain information [8]. Web server load information can also be used to enhance the load balancing algorithm. The main idea of using load information is to assign under-loaded web servers to address resolving requests more frequently. The simplest load balancing algorithm using load information is Asynchronous Alarms (AAlarm) algorithm. With AAlarm, each web server will calculate its own utilization periodically and send alarm messages with the load state information to the DNS. If one web server is overloaded, the DNS will not map address requests to that server until it goes back to not-over-loaded state. In our simulation, simple AAlarm algorithm is coupled with the Round Robin algorithm. Also, we can take advantage of both kinds of information. The RR2+AAlarm algorithm is the combination of RR2 and AAlarm algorithms, and uses both client domain information and server load information. 2.2. Page Caching Policies In general, page caching could reduce the traffic loads on web servers and possibly reduce the response time. However, simple caching policy, which caches all pages whenever possible, can only yield a hit ratio up to 3-5%, no matter what replacement algorithm is used [2]. Moreover, caching a new page may replace multiple cached pages, and the invalidated web pages may be requested soon. In this situation, the cache miss ratio will increase. If the new web page is of a very large size, the number of cached pages to be invalidated may be very large, and the negative effects of cache replacement may be large too. To reduce the impact of this problem, we can modify the original caching policy and cache web pages of small sizes only. If the size of a web page is less than a pre-determined threshold T size, the cache will cache it; otherwise, the cache ignores it. We call this caching policy Caching with Size Limit. Furthermore, previous work [][4][5] discovered that most page requests went to a small portion of web pages and the total number of requests towards other pages was not negligible (see section 3.2 for details). In this situation, simple caching policy, which treats web pages equally, may not have satisfying performance. The reasons are as follows: Caching a non-hot page may be useless because next request for this page tends to be made after a long time, and the cache line for this page will probably be invalidated before next request, due to the large amount of caching actions for other pages made during the interval. Also, caching of non-hot pages may invalidate some cached hot pages due to limited space of the cache. To avoid this problem, we can cache hot pages only instead of all pages. Similar policies have been suggested in some caching/prefetching approaches [3]. Although the cache itself can collect enough information for identifying hot pages, we do not prefer this method due to the heavy computation burden on the cache. We suggest moving the hot page judgement to the web server system. For each period, the DNS collects the number of accesses towards each active page, and calculates the average access number N avg. Then it calculates the hot threshold T hot by multiplying N avg with a given hot factor f hot : T hot = N avg f hot After that, the DNS will compare access number of each page with this threshold. If the access number is larger than the hot threshold, the page is marked as a hot page; otherwise it is a non-hot page. When web servers respond to http requests for hot pages, they will set these pages as cacheable. In this way, the cache can only cache hot pages. Similarly, we can combine the policy Caching Hot Pages Only with the policy Caching with Size Limit together. 3. Web Traffic Models We use stochastic processes to model web traffic, use these models to generate traces, and evaluate the performance of various algorithms by applying generated traces into simulation. The simulation models include client distribution model, file size and access pattern models, and traffic model. 3.. Client Distribution Model The non-uniform distribution of clients is one major reason why there may be load imbalance among distributed web servers. Study shows that, on average, 75 percent of the client requests come from only percent of the domains [4]. A good approximation that fits this non-uniform distribution is the Zipf function. The Zipf distribution can be represented by Z i = c/i x where Z i is the number of clients in i-th domain, x is a parameter, and c is a constant given by L c =[ i= ] i x where L is the number of local domains (gateways). The pure Zipf function is the Zipf function with x =. In our simulation, we use pure Zipf distribution to approximate the client distribution associated with local gateways. Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

3.2. File Size Model and File Access Model Researches show that sizes of accessed web files can be approximated by the power-law (Pareto) distribution [][4]. The probability density function of power-law distribution is p(x) =αk α x α and its cumulative distribution function is given by Prob{X x} = (k/x) α α, k, x k The power-law distribution has a few properties that are different from most of other distributions. It has a heavy tail and can give rise to extremely large values with nonnegligible probability. Study shows that distribution of Internet web file sizes fits to the power-law with α.63 [4]. Moreover, the file access pattern follows the Zipf distribution with parameter x larger than (for a homogeneous environment, x appears to be around.2), and there is little correlation between the page access frequency and its size or between the page access frequency and its change rate [5]. Also, among web files, only a small portion of files are accessed frequently (about 5%-8% traffic goes to % files) and around one-third accessed files are accessed just once [][4][5]. To simplify the calculation, we use pure Zipf distribution to approximate the file access pattern. 3.3. Traffic Models Although the WWW traffic models are still under study, some characteristics of Internet traffic have been discovered. A web page normally consists of a few page components. When a client requests a web page, it will request all page components separately. We call one successful access to a page component a hit. The number of page requests per session and the inter-request time are exponentially distributed [4], and the number of hits per page access is roughly 7 and this value tends to increase [8]. Similar to [8], we model the number of hits per page as a uniformly distributed number over [5, 5]. In our simulation, we relate the service time for each hit to the web page size linearly, and set the mean value of service time to a few milliseconds. 4. Performance Metrics and Simulation Results 4.. Performance Metrics In this paper, we use two metrics to evaluate the load balance performance. The first metric is the cumulative frequency of maximum utilization. We divide the simulation time into n time slots, and for each time slot j, there is a server utilization U j i associated with each web server i. Maximum utilization U j max is the maximum value among all web server utilization in time slot j. The cumulative frequency CDF(x)is defined as the probability that maximum uitlization is less than or equal to x: CDF(x) =Prob{U max x} Num(U j max x) n where Num(Umax j x) is the number of time slots in which maximum utilization is no larger than x, and n is the total number of time slots. For a given traffic load, if one web server handles more traffic, other web servers will handle less traffic. This situation will yield larger maximum utilization. Thus larger maximum utilization suggests larger load imbalance among web servers. In a graph with multiple curves of cumulative freqencies, the leftmost curve corresponds to the best performance. Also, for the same cumulative frequency, higher maximum utilization means worse performance. The second performance metric for evaluating load balance is the standard deviation of server utilization. For a given time slot j, the instant standard deviation SD j is calculated by SD j = K (U j i U avg) j 2 /K i= where K is the number of web servers, and Uavg j is the mean of server utilization U j i, i =,.., K. Then, the standard deviation SD is calculated by averaging all instant standard deviation values. If servers working loads are evenly distributed, the standard deviation would be very small. Therefore, smaller the standard deviation, better the load balance. Other two performance metrics used in this paper is the average utilization of web servers and cache hit ratio. These two metrics are used to evaluate the cache performance. Our simulator is written using the general purpose simulation package CSIM []. Table lists some default simulation parameters. If not stating otherwise, we use default parameters in our simulation. 4.2. Performance of Load Balancing Algorithms In this subsection, we compare the performance of several load balancing algorithms with the existence of page caching. Here, we choose four algorithms in our simulation, which are RR, RR2, AAlarm, and RR2+AAlarm they correspond to four algorithm categories of not using any state information, using domain information, using server load information, and using both domain and load information respectively. The page cache used in our simulation is a Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

Parameters Values Number of web servers 7 Number of gateways 2 Number of clients 5 Number of files 64K/server Average file size Approximately 6K bytes Client distribution Pure Zipf File size distribution Power-law with α in [,.63] File access pattern Pure Zipf Web page requests per session Exponential (mean 2) Hits per request Uniform over [5, 5] Hit service time Mean 4.5ms, related to page size Inter-request time Exponential (mean 5 seconds) Address TTL value 3 seconds Page TTL value 24 seconds Cache Replacement Policy Least Recently Used (LRU) Table. Default Simulation Parameters 4MB server-side cache that uses simple caching policy. Recall that the number of page files is 64K and average file size is 6KB in our simulation (see Table ). So the total file size in each web server is 64K 6K=GB, and a 4MB cache can cache about % of files. Standard Deviation of Utilization.7.6.2 4 Server side Cache Size (MB) RR RR2 AAlarm RR2+AAlarm Figure 3. Comparison of Load Balancing Algorithms : Standard Deviation of Server Utilization Simulation results are given in Figure 2 and Figure 3. Figure 2(a) shows the performance of load balancing algorithms without page caching, and Figure 2(b) presents the performance of algorithms with existence of server-side page caching. Figure 3 shows the performance of load balancing algorithms in terms of standard deviation of server utilization. From both figures, we can find that the algorithm RR2+AAlarm always yields best load balance performance, no matter whether there is page caching. RR2+AAlarm utilizes both the domain information and the server load information, and leads to larger performance improvement than individual RR2 or AAlarm algorithm. Therefore, we can conclude that taking advantage of both domain information and load information could significantly improve the load balance of DNS-based web server systems either with or without the existence of page caching. In addition, comparing simulation results with a serverside cache to those without caches, we can find that adding a page cache at the server side improves the system performance and reduces the load imbalance. 4.3. Effects of server-side caches and client-side caches In this subsection, we study the effects of server-side caches and client-side caches on the system performance of load balance. To make the comparison fair, we set the total size of client-side caches equal to the size of server-side cache, and all client-side caches eqaully share the total size. Because the total file size of each web server in our simulator is GB, each MB cache size can accommodate about % of files. Here, we use the algorithm and simple page caching policy. Simulation results are given in Figure 4 and Figure 5. Figure 4(a) and Figure 4(b) show the distribution of maximum utilizations when with server-side caches only and with client-side caches only respectively. As discussed above, the leftmost curve of maximum utilization corresponds to the best load balance performance. We can find that client-side caches have much smaller effects on the load balance. With the increase of total size of client-side caches, there are only small changes on the cumulative frequency of maximum utilization of the web server system. On the other hand, with the increase of server-side cache size, the distribution of maximum utilization changes a lot. With same (total) cache size, a server-side cache can yield much greater improvement on load balance than client-side caches. Figure 5 shows the effects of server-side caches and client-side caches on the system average utilization, standard deviation of server utilization and cache hit ratio. From Figure 5 (a), we can find that, with the increase of clientside cache sizes, there is only a little change on the standard deviation of server utilization, although there are an increase on the cache hit ratio and a small decrease on the average utilization of web server system. On the other hand, the server-side cache is totally different (see Figure 5 (b)). With the increase of cache size, a server-side cache yields significant improvement on cache hit ratio, average utilization and standard deviation of server utilization. For example, when the cache size changes from 2M to 4M, there are about 2.9% increase on cache hit ratio (from 2 to 87), 8.5% decrease on average utilization (from 28 Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

.6.7.8.9.9 RR RR2 AAlarm RR2+AAlarm.9 RR RR2 AAlarm RR2+AAlarm.8.8.7.7.6.6.2.2.6.7.8.9 (a) Without caches (b) With server-side cache (4MB) Figure 2. Comparison of Load Balancing Algorithms :.9.8 Cache Size = Cache Size = MB Cache Size = 2 MB Cache Size = 4 MB Cache Size = 8 MB Cache Size = 6 MB.9.8 Cache Size = Cache Size = MB Cache Size = 2 MB Cache Size = 4 MB Cache Size = 8 MB Cache Size = 6 MB.7.7.6.6.2.2.6.7.8.9.6.7.8.9 (a) Client-side caches (b) Server-side cache Figure 4. with Different Caches and Cache Sizes to 83), and.8% decrease on standard deviation of server utilization (from 783 to 376). The possible reason for the difference between effects of a server-side cache and client-side caches is that, the server-side cache serves all page requests while the clientside caches only serve the page requests from their own domains. Therefore, duplicate copies of web pages may reside in multiple client-side caches, and it makes the client-side caches less efficient. 4.4. Impacts of Page Caching Policies For page caching policies, we have four choices: () Simple caching, which caches any web pages whenever the page sizes are less than the cache size ; (2) Caching with Size Limit, which only caches pages with sizes less than a given threshold; (3) Caching Hot Pages Only, which only caches popular web pages dynamically determined by the web server system; and (4) Combination of the second and the third policies. In this subsection, we study the impacts of page caching policies on the system performance of load balance. Here, we consider the algorithm RR2+AAlarm and the server-side cache in this subsection. Figure 6 illustrates the load balance performance of the web server system with a 4MB server-side cache and different page caching policies. Figure 7 shows the system performance in terms of average utilization, standard deviation of server utilization and cache hit ratio under different page caching policies and with different server-side cache sizes(2mb, 4MB and 8MB). Here, the hot factor (see section 2.2) is 6, and the threshold for Caching with Size Limit is 6KB. It can be noticed in Figure 6 that, all caching policies have positive effects on the system load balance. The policy Caching Hot Pages Only can yield more significant improvement on system performance of load balance than other caching policies. Moreover, two policies involving Caching with Size Limit even worsen the load balance performance with comparison to simple caching policy. Although Caching Hot Pages Only brings a large improvement on the load balance, the combination of it with the policy Caching with Size Limit performs even worse than simple caching policy. However, Caching with Size Limit is a good policy on improving the cache hit ratio. From Figure 7, we can see that this policy yields best cache hit ratios in most situa- Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

2 4 6 8 2 4 6.7.7.6.6.2.2 Average Utilization Standard Deviation Cache Hit Ratio Average Utilization Standard Deviation Cache Hit Ratio Total Size of Client side Caches (MB) (a) Client-side Caches 2 4 6 8 2 4 6 Server side Cache Size (MB) (b) Server-side Cache Figure 5. Average Utilization, Standard Deviation and Cache Hit Ratio with Different Caches and Cache Sizes.9.8.7.6.2 Without Page Caching Simple Page Caching Caching with Size Limit 6KB Caching Hot Pages Only Caching Hot Pages with Size Limit 6KB.6.7.8.9 Figure 6. with Different Caching Policies tions. But the improvement on cache hit ratio by this policy does not lead to the improvement on server utilization and load balance. On the other hand, the improvement on cache hit ratio by Caching Hot Pages Only is not so large as by Caching with Size Limit, but Caching Hot Pages Only yields more significant improvement on average utilization and load balance. Also, it is interesting that the improvement on load balance by Caching Hot Pages Only tends to be higher when the cache size becomes larger. With the increase of server-side cache size from 2MB to 4MB and 8MB, the improvement on standard deviation of server utilization increases from 8.22%(783 472) to.6%(376.2984) and 3.68%(44.274), compared with the standard deviation of simple caching policy. Recall that web accesses are non-uniformly distributed and most page requests are towards a small portion of web files. Caching hot pages can efficiently reduce the probability of useless frequent replacement and therefore increase the cache hit ratio. With higher cache hit ratio, the cache would serve more page requests directly. Since overloaded web servers receive much more page requests than other web servers, they can benefit more from the improvement on cache hit ratio. Therefore, Caching Hot Pages Only can bring more significant improvement on the system load balance. On the other hand, Caching with Size Limit increases the cache hit ratio, but this increase is caused by caching more web pages in the cache and has an expense that the cache doesn t serve web pages of large sizes. Because the number of large files is much less than the number of small files(see subsection 3.2), the accesses to large files are more likely to be distributed skewedly to web servers. For example, assume we have three web servers and the probability that one request goes to any one web server is /3. If we have 3 page requests, the probability that all three requests go to one particular web server is /27; but if we have requests, the probability that more than 8% requests go to one particular web server is k=8 Ck /3 k which is less than 8. Furthermore, the service cost for a large page will be much higher than that for a small page. So Caching with Size Limit results in a worse load balance even though it improves the cache hit ratio a lot. 5. Conclusions and Future Work In this paper, we examined various caching strategies for a DNS-based distributed web server system, and evaluated their load balancing performance based on simulation results. Our findings include: () When we design the load balancing algorithm for the DNS, taking advantage of both client domain information and server load information would lead to best load balance performance either with or without the existence of caches; (2) Server-side caches have much larger impacts on the load balance performance of the DNS-based web server system than client-side caches; (3) Caching popular web pages is an efficient policy in fur- Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE

2 3.8.7 Simple Page Caching Caching with Size Limit 6KB Caching Hot Pages Only Caching Hot Pages with Size Limit 6KB.6 Simple Page Caching Caching with Size Limit 6KB Caching Hot Pages Only Caching Hot Pages with Size Limit 6KB.8.7 Simple Page Caching Caching with Size Limit 6KB Caching Hot Pages Only Caching Hot Pages with Size Limit 6KB.6.6 Average Utilization Standard Deviation Cache Hit Ratio.2.2.2 2 3 2 3 k : Server side Cache Size = 2 k MB k : Server side Cache Size = 2 k MB k : Server side Cache Size = 2 k MB (a) Average server utilization (b) Standard deviation of server utilization (c) Cache hit ratio Figure 7. Average Utilization, Standard Deviation and Cache Hit Ratio with Different Page Caching Policies and Server-side Cache Sizes ther reducing server utilization and improving load balancing performance, while caching small pages only have effects on further increasing cache hit ratios. We believe these findings can provide some guidances on establishing an efficient DNS-based distributed web server system. However, in this paper, we only examined comparably simple caching strategies. In the future, we would investigate more sophisticated caching methods suitable for DNSbased web server systems, such as prefetching [2] and cooperative caching [5]. As mentioned in previous section, prefetching may cause undesired traffic bursties and queueing effects. So we have to carefully design and tune prefetching algorithm to avoid the possible negative effects. Also, cooperation mechanisms between the serverside caches and/or the web server system may produce additional network traffic and server workload. But we believe, if cooperation is carefully designed, the overhead would not be too high and could be digested without significantly affecting the network performance. References [] Csim user guide. online documentation, Mesquite Software, Inc. http://www.mesquite.com/documentation/index.htm. [2] M. Abrams, C. R. Standridge, G. Abdulla, S. Williams, and E. A. Fox. Caching proxies: Limitations and potentials. Proceedings of the 4th International WWW Conference, Boston, MA, Dec. 995. [3] G. Apostolopoulos, D. Aubespin, V. Peris, P. Pradhan, and D. Saha. Design, implementation and performance of a content-based switch. Proceedings of INFOCOM, Tel Aviv,, March 2. [4] M. F. Arlitt and C. L. Williamson. Web server workload characterization: The search for invariants. IEEE/ACM Trans. on Networking, 5(5), Oct. 997. [5] L. Breslau, L. F. Pei Cao, G. Philips, and S. Shenker. Web caching and zipf-like distributions: Evidence and implications. Proceedings of INFOCOM 99, March 999. [6] V. Cardellini, M. Colajanni, and P. S. Yu. Dynamic load balancing on web-server systems. IEEE Internet Computing, 3(3):28 39, May-June 999. [7] E. Casalicchio, V. Cardellini, and M. Colajanni. Contentaware dispatching algorithms for cluster-based web servers. Cluster Computing, Kluwer Academic Publishers, 5():65 74, Jan. 22. [8] M. Colajanni, P. S. Yu, and D. M. Dias. Analysis of task assignment policies in scalable distributed web-server systems. IEEE Trans. on Parallel and Distributed Systems, 9(6), June 998. [9] M. Crovella and P. Barford. The network effects of prefetching. Proceedings of INFOCOM 98, San Francisco, CA, March 998. [] C. R. Cunha, A. Bestavros, and M. E. Crovella. Characteristics of www client-based traces. Technical Report BU-CS- 95-, CS Dept., Boston University, April 995. [] B. D. Davison. Web traffic logs: An imperfect resource for evaluation. Proceedings of the ninth Annual Conference of the Internet Society (INET 99), San Jose, CA, June 999. [2] J. Jung, D. Lee, and K. Chon. Proactive web caching with cumulative prefetching for large multimedia data. Computer Networks, 33:645 655, 2. [3] E. P. Markatos and C. E. Chronaki. A top- approach to prefetching on the web. Technical Report 73, Institute of Computer Science(ICS), Foundation for Research & Technology(FORTH), August 996. http://www.ics.forth.gr/proj/arch-vlsi/www.html. [4] A. Nanopoulos, D. Kastasaros, and Y. Manolopoulos. Effective prediction of web user accesses: A data mining approach. Proceedings of the Workshop WEBKDD 2: Mining Log Data Across All Customer Touch-Points, San Francisco, CA, Aug. 2. [5] S. Paul and Z. Fei. Distributed caching with centralized control. Computer Communications, 24:256 268, 2. [6] A. Venkataramani, P. Yalagandula, R. Kokku, S. Sharif, and M. Dahlin. The potential costs and benefits of long-term perfetching for content distribution. Technical Report TR--3, Dept. of Computer Science, Univ. of Texas at Austin, USA, June 2. Proceedings of the Tenth International Conference on Parallel and Distributed Systems (ICPADS 4) 52-997/4 $ 2. IEEE