Emulating Web Cache Replacement Algorithms versus a Real System L.G. Cárdenas, J.A. Gil, J. Sahuquillo and A.Pont1 Polytechnic University of Valencia, Camino de Vera, s/n Valencia, 46022 SPAIN
[email protected], {jagil, jsahuqui, apont}@disca.upv.es
Abstract This paper presents a powerful framework to simulate web proxy cache systems. Our tool provides a comfortable environment to simulate and explore cache management techniques. It also includes an extension to design and simulate new structures considering several inter-connected caches which are very convenient for our current research projects. Besides a statistics module is enlarged to obtain supplementary performance measures. We compared the results obtained from our framework against a commercial proxy cache system by using several replacement algorithms and input traces. Experimental results show that proxy cache hit ratio deviations fall very close to the real system, since them never exceeds 3.5%. Although the simulation time varies depending on the input trace size and the modeled management technique, in all experiments run time has been by about several hundred times faster than the time the real system takes.
1. Introduction Proxy web caches behave as web objects deposits attending user requests instead of being attended by origin web servers. Different techniques have been implemented in proxies to increase performance and to reduce latencies when users navigate the Web. An important set of them are those focusing on caching management techniques, whose main goal is to keep close to the users the most popular contents. These techniques also reduce network traffic since they avoid unnecessary requests to origin servers.
We have proposed a Proxy web cache simulator [7] which allows simulation of proxy cache multi-key management techniques . Under the term multi-key we refer to those algorithms which sequentially apply several object characteristics (e.g., the object size and the frequency of use) to decide which object or objects must be evicted. This simulator is coded in a modular way, allowing fast implementations of desired algorithms in a robust and easy way. As particular novelty our tool provides the basic software structures to design and simulate several inter-connected caches instead of only one, since this is one of the main ideas currently explored in our research projects. In addition, the tool has been enriched by providing a large variety of statistics for performance comparison purposes. We compare our simulation framework against a real proxy cache to show how accurate it performs. For this purpose we select the real Squid Web Proxy Cache. For comparison purposes, the proxy cache hit ratio and number of evictions from the cache were used as metrics. Experiments were run under different conditions (traces and cache management techniques). Results show that our tool performs very close to the real proxy cache. The maximum deviation of the cache hit ratio never surpasses 3.42%; moreover, in 4 out of 12 cases is below 1%. In addition, the simulation time ranges from ten to hundred times faster than the emulated real system without losing accuracy. The remainder of this paper is organized as follows: Section 2 discusses some related work of web caching simulation environments. Section 3 briefly describes the structure and main characteristics of our simulator. In Section 4 we describe how original proxy traces were prepared to feed the emulated real scenario and the simulation framework. The Squid’s caching
1
This work has been partially supported by the: Spanish Government Grant CYCYT TIC2001-1374-C03-02, Mexican Government Grant CONACYT 177846/191901.
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
behavior is described in Section 5. Section 6 explains the comparison of both scenarios, completed with performance results. And finally, Section 7 presents the main conclusions of this work.
2. Related Work In this section we present the main characteristics of a representative set of cache simulators. We mainly concentrate if their performance were checked against real systems. Cao proposed the Web Cache simulator [6] which is a fast trace-driven simulator written in C programming language. The simulator manages a priority queue to implement replacement algorithms (e.g. LRU, SIZE, LRV and HYBRID). This type of algorithms employs a unique field, such as size, frequency, last access time, to determine the object to evict from the cache when new space is required. This simulator focuses mainly on caching techniques and, to our knowledge no comparison against a real system has been done. Davison developed the trace-driven Network and Cache Simulator (NCS) [9] (which simulates prefetching techniques. Caching is an optional feature simulated in a very simple way. The simulator models network aspects such as DNS effects, idle times, connection and waiting times. Experiments performed to validate NCS [10] include a small-scale test, and a large one using UC Berkeley Home IP HTTP traces. The latter experiment focuses strictly in how to validate portions of networks models considered in the simulator. The process compares responses times in the traces against the simulated latencies. Proxim [4] is a caching and network simulator that emulates proxy caches using log traces. This simulator considers interaction between HTTP and TCP messages and their network environment. It takes into account several factors that could affect object transferences, such as storage restrictions in some HTTP headers, and data in-transit during connection aborts. Feldmann [13] use Proxim to analyze the impact on latencies and bandwidth due to proxies. The experiments use only the LRU algorithm with an infinite cache size, therefore no replacements occurred. No performance comparison was done for caching characteristics.
3. Proposed Web Cache Simulator Our framework is a trace-driven proxy cache simulator, based on a previous single tool presented in [7]. The simulator allows to model cache management techniques considering multi-key algorithms in single
and multiple cache structures. Coded using classes in C++ programming language, it provides a framework that permits quick implementations of cache placement and replacement algorithms. Therefore, it offers a convenient scenario to do comparison studies. The tool is composed by two main modules, a filter module and the cache simulator. The filter module prepares original proxy logs to feed the cache module, which simulates a web cache structure. In the current version, the filter module only accepts squid-proxy logs, but it can be easily modified to incorporate more types of proxy logs such as Harvest, DEC, UCB, CRISP, etc. Like in the Squid proxy cache [16] our simulator uses the Message Digest Algorithm (MD5) [15] to codify each URI. This algorithm guarantees an unique 128 bits footprint from any arbitrary URI (or any other input). Due to the relatively small size of the footprints, the object search time in the web cache structure is quicker than using the full URI as object label. Another optional feature offered by the filter module is that log requests can be filtered by web object type (e.g., gif, jpg, html, dynamic) or by HTTP result code. In addition, the filter program estimates latency related parameters per request used in the cache simulator. These parameters estimates a mean response time per request (conformed by a latency per each request and a penalty time for each miss). The cache simulator module takes as input a log prepared by the filter module and a parameters file with the cache characteristics, and it generates a statistics file. Main performance statistics obtained are: hit ratio (HR), byte hit ratio (BHR) and the mean response time per request. The simulator module is implemented using two object oriented classes. The cache class which reproduces the behavior of a cache (e.g., adding, evicting, moving, locating web objects), and the abstract web object class that represents the objects contained in the cache. The cache class is defined by two data structures: The Object Location Structure (OLS) used to perform fast searches in the cache structure, and the Priority Ternary Tree (PTT) used to maintain objects ordered by a given priority (the least priority objects are selected for eviction when space is required). The OLS is composed by an array of pointers and several binary trees. The array has 2n elements indexed with the n less significant bits (n is set to 16 by default) of the 128 MD5 web object URI identifier (coded for each object URI in the filter module). Each element in the array points to a binary tree whose nodes point to web objects in the PTT structure. The meaning of the priority of a web object in the PTT structure depends
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
on the implemented replacement policy (e.g., size, frequency of use, or a combination). One important feature of the PTT is the quick access to the least priority objects, which accelerates object evictions. On the other hand, the web object abstract class defines basic characteristics for objects in cache. This includes typical properties such as size, popularity, and the URI for each web object. This class also defines three priority methods: greater, less and equal, which are used for comparing priorities when inserting objects in the cache structure. These methods permit to traverse the tree in order to accommodate objects in the PTT according to their priority. Cache.h
Abstract_WebObject.h
Web Object Abstract Class
Basic Web Object Properties
URI, Size, Frequency
1 Web Object Derived Class
uses
derive
uses
Overide Priority Methods GreaterPriority() equalPriority() lessPriority()
uses
Cache Class
insertWebObject() reinsertWebObject() evictWebObject() locateWebObject()
Algorithm Implementation
2 main()
Web Servers (Internet)
Single Cache Structure
…
Multiple Cache Structures
Figure 2. Single and multiple cache Structures of MSE Additionally, the OLS structure permits to retain historical data of objects of the cache structure. As a consequence, we can obtain information such as webobject-tours (the number of times an object enters the cache during the simulation session). This kind of information is useful to better understand the behavior of web objects and client access patterns.
4. Preparing Proxy Cache Logs
2 SIZE_Simulator.cpp
SIZE_WebObject.h
Figure 1. Relation between the two classes used in our simulator to implement SIZE algorithm Figure 1 shows the elements and the corresponding files that must be modified to implement a new cache management technique. First, a new web object class is derived from the abstract web object class (1) — priority methods must be overridden according to the proposed technique—. Second, such technique is implemented by using the cache interface functions of the cache class, and the new web object derived class (2). Our framework is also able to simulate multiple cache structures that cooperate and interchange information between them as shown in Figure 2. This is an interesting feature for our research projects where new cache managements techniques are being explored.
The simulation framework was compared against a real proxy cache using 4 different traces each one containing between 4.2M and 6.5M requests. Traces were collected from a real Squid proxy cache placed at the Polytechnic University of Valencia. All logs correspond to a browsing user’s activity period of 2 typical days in the campus. We refer them as Log A, Log B, Log C and Log D. Logs require a two-phase filter preparation before obtaining final traces to feed both scenarios. Table 1 shows the percentage of logs for HTTP [14] categories (i.e. 2xx, 3xx, 4xx, 5xx) over the total trace for Log A and Log B, Log C and Log D (0xx and 1xx are discarded because their percentage is negligible). We also show the percentage for HTTP subcategories 200, 302 and 304 that comprise more than 89% of requests in all traces. Due to the nature of each subcategory, a preparation is required before include them in the comparison experiments.
Table 1. Percents over the total trace of original proxy logs broken down by HTTP status code categories HTTP/1.1 Category Log A Log B Log C Log D
2xx 200 49.00 53.36 53.56 60,88
Total 48.74 54.46 54.27 62.60
302 19.35 15.15 18.69 6,99
3xx 304 21.52 25.92 23.94 27,43
4xx Total 47.39 41.33 42.83 34,66
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
404 1.30 1.56 1.36 1,49
Total 1.42 1.70 1.56 1,63
5xx Total 0.28 0.24 0.24 0,30
HTTP 200 status code responses confirm successfully received, understood and completed requests. From this group, we have excluded dynamic content (i.e., web objects generated dynamically by web servers) because proxy caches do not store them although several works [3] [5] [12] [17] [18] [19] investigate the convenience about consider this content as cacheable. The HTTP 302 status code responses denote temporal redirection of the request, and these requests are only cacheable if specific headers are provided. We discard them because this information is not given in original proxy logs. The HTTP 304 status code responses refer to short verification messages of type if-not-modified-since sent by clients to verify object freshness. Original proxy logs do not reflect real object size for these requests; and therefore an additional filter is set up to include them in simulations. The 4xx and 5xx are HTTP error response categories; therefore, also excluded from the experiments because they represent errors generated outside of the proxy cache scope (4xx corresponds to client mistakes and 5xx proceeds from internal server errors). Remaining categories of 2xx and 3xx codes are considered noncacheable as recommended in [14] [16]. A two phase filter is set up to prepare traces for both scenarios. The first-stage is performed by the filter module of the simulator. In this filter we discard requests with HTTP error response categories (i.e., 4xx, 5xx), 302 HTTP subcategory, dynamic content and the remaining non-cacheable subcategories. For each original trace used we obtain a first-stage trace used as input in the second-stage filter. Then, the second-stage filter prepares traces to reflect real object size for remaining requests with HTTP 304 status code category. Table 2 shows percentage over total trace of HTTP subcategories after first-stage filter. Table 2. Percentage of HTTP 200 and HTTP 304 responses of First-stage traces First-stage traces
HTTP/1.1 Subcategories
Log A
Log B Log C
Log D
HTTP 200
69.48
63.18
65.45
64.91
HTTP 304
30.52
36.82
34.55
35.09
Second-stage filter consists of obtaining real object size for 304 status code responses of first-stage traces. Object size is needed by any cache management algorithm throughout simulations. Therefore, we prepare an experimental scenario to obtain a Squid trace with only HTTP 200 subcategory status code responses as follows: i) First, we copied in an experimental Apache those objects in the first-stage
trace from the original servers in Internet by using wget web client (left side in Figure 3) ii) Then, the first-stage trace was artificially replied against an experimental Squid proxy cache (right side in Figure 3). All accesses which produce a miss in the Squid were forwarded to the Apache web server (down side in Figure 3). Squid logs were recorded into a second-stage trace. Data in these traces showed that some requests in the resulting log were HTTP 404 NOT FOUND subcategory responses, which appeared because many objects from the first-stage filter could not be downloaded into the Apache web server due to objects are erased constantly from Internet. Notice that first-stage trace did not contain any object with this code, because these objects were removed by the first-stage filter. Therefore, we apply again this filter to the second-stage trace, giving a final trace with only the HTTP 200 response codes, which is able to feed both environments.
Trace with HTTP 200 and 304 requests
Ask for objects in first-stage trace
Original servers
...
S1
GNU Wget web client
First-stage trace
Experimental proxy Initially empty
Sn
Requests Log
S2
(isolated from internet) To isolate from internet
S1
S2
...
Sn
Si represent objects copied from original server i
Second-stage trace
HTTP 4xx and 5xx requests appear
Repeat First-stage filter Final trace
Only remains 200 HTTP requests
Apache web server
Figure 3. Second-stage filter
5. The Real Proxy Server: Squid The open source Squid Web Proxy Cache version 2.5.STABLE-4 was selected as the real web proxy cache for comparison purposes. Real environments usually are much more complex than simulation environments. Therefore, some assumptions must be performed to simplify the real world. In this section, we firstly identify and describe the particular characteristics of the Squid proxy cache, then we analyze how to tune Squid in order to match simulation behavior. Finally, a comparison is performed to detect the sensibility of the changes.
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
5.1. Squid behavior Classical replacement algorithms check if there is enough space on cache to place the requested object. If there is not, one or several objects must be evicted in order to make space for the new one. Under the term on-demand we refer to such behavior adopted in many simulation environments [2]. Instead, Squid avoids to over pass the cache space size, controlling the percentage of the cache occupied by the stored objects. To this purpose, Squid sets a critical percentage zone that, when reached, objects must be evicted. That zone has a lower threshold and an upper threshold set in configuration file (defined in Squid as low water mark and high water mark respectively). Squid periodically verifies (every second by default) the percentage of occupation using equation 1. Then two formulas (equation 2 and equation 3) are used to select the objects to be removed. Equation 1 estimates the percentage occupied by objects and Equation 2 uses this value to estimate the number of objects that can be removed. Objects not considered are non-blocking objects (objects pending to swap-out to disk or being served to a client) and partially received objects. Equation 3 selects the maximum number of objects to be removed. Finally, these objects are removed one by one, until all of them are removed or the lower threshold level is reached. f =
cache _ occupied − low _ watermark high _ watermark − low _ watermark
(eq. 1)
scan = ( f * 400 + 100 )
(eq. 2)
max_ remove = ( f * 70 + 10 )
(eq. 3)
5.2. Tuning Squid Three main Squid features were identified to be tuned in order to model classical simulation environments [2]: i) the number of buckets, ii) the watermark levels, and iii) the period of time to check cache occupation. The first one only requires adjusting the corresponding parameter in the configuration file, while the remaining ones require code modifications.
To guarantee this behavior we set to 1ms the period of time to check the occupation level is and the minimum time inter requests. Really, we are not modeling an exact on-demand behavior, but this approach is quite accurate. Notice that if an object surpasses the low level mark, a new space will be free on the next occupation check to keep the level under this mark, which will be take place before the arrival of another object. 5.2.2. Modeling the cache size. We use the critical zone as a buffer to place temporally an incoming object until the next check of the occupation level. Therefore, this critical zone is a virtual space storage that must not be considered when modeling the cache size. In the Squid configuration file, the lower threshold parameter is set to 95% of the total cache size. 5.2.3. Checking the on-demand behavior. The changes discussed above were introduced in an ondemand Squid and its performance compared against a normal implementation of Squid to detect inconsistencies. Table 3 shows the results after replaying a subset of requests from one of the mentioned logs for an 11MB cache size. As we can see slightly differences appear in the hit ratio and number of evicted objects. Increments are due to the strict control enforced in the on-demand squid. In these experiments cache disc space is set to 11MB. Squid must also reserve a cache area in main memory. This area (set to 1 MB) is used to place: i) intransit objects, ii) hot objects (those most requested by users), and iii) negative-cached objects (dynamic objects temporally stored by Squid). In addition, we also found some errors generated by Squid (i.e., SwapOut-Fail entries). These errors are logged in a Squid file used to estimate the number of evictions. We check different configurations in order to obtain a negligible number of fails and concluded that small cache size generate them.
Table 3. Measured metrics in the normal and on-demand Squid Metric
5.2.1. Forcing on-demand Squid behavior. As mentioned above, Squid replaces a set of objects until the low water mark is reached. What we pursue is to model as close as possible an on-demand behavior. In other words, to free the required space only when one (or several) object arrives, depending on the space needed by the incoming object.
Normal Squid
On-demand Squid
Hit Ratio
0.1557
0.1600
Evicted Objects
104,947
104,351
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
6. Performance comparison phase This section compares results obtained from the experimental Squid proxy cache of the emulated scenario against the simulation environment. Our comparison considers as metrics the hit ratio and number of evictions of all caching algorithms included in Squid. Figure 4 shows this process. In Squid the replacement algorithms were enabled and finally implemented in the simulator considering the same characteristics. Real scenario emulated
large number of evictions take place, given the required conditions. Table 4 shows the cache hit ratio in the compared systems for LRU, LFUDA and GDSF replacement algorithms; using Log A, Log B, Log C and Log D final traces. Notice that in 4 of 12 cases hit ratio deviations of our tool are less than 1%, in seven cases never surpass 3% and only one reaches top value of 3.42%. Also remark that the hit ratio from the emulated scenario resembles the behavior described in [11] (i.e., GDSF obtains the higher hit ratio and LRU the lowest). Table 4. Proxy cache hit ratio for both scenarios
Simulated side
Final traces A, B, C, D
MSE Filter Module
Experimental web proxy
Replacement algorithms modeling
Squid log files
Hit Ratio MSE simulation framework
Algorithm
Squid
MSE
%
Log A
LRU
48.83
50.16
2.72
LFUDA
50.78
51.15
0.73
GDSF
57.83
56.77
-1.83
LRU
47.76
48.06
0.63
LFUDA
48.61
48.43
-0.37
MSE statistics
Log B Compare cache performance metrics
Figure 4. Validation process for our simulator Any kind of algorithm (single key, multiple key) can be easily modeled in our framework. Replacement algorithms included in the Squid 2.5 web proxy cache modeled in MSE are: i) LRU (least recently used), ii) LFUDA (least frequently used dynamic aging) [1] which applies equation 4 to calculate the key value used to select objects to be evicted; and iii) GDSF (greedy dual size frequency) [8] (equation 5). In LRU objects referenced for the last time are evicted, while objects with the smaller key in LFUDA and GDSF are evicted. To compute the key value, Squid uses timestamps given by the machine clock in the aging mechanism; therefore, simulation approaches will introduce a precision lost. We model the time-stamp by adding one tick each time a request arrives. Time arrival will decide which object is evicted for objects with equal key values (i.e., time-tie breaker). (eq.4) LFUDA_ Key _ Value(obj i) = squid _ aging _ mech +
freq(obj i) − tie _ break size(obj i)
(eq. 5) GDSF _ Key _ Value(obj i) = squid _ aging _ mech + freq(obji) − tie _ break
In the comparison study experiments were run considering 256MB cache size in both scenarios. This value is much smaller than the total amount required by objects in the used trace (about 20 GB); therefore, a
Deviation
Traces
Log C
Log D
GDSF
58.26
56.81
-2.50
LRU
49.14
50.82
3.42
LFUDA
51.25
52.00
1.46
GDSF
58.25
57.34
-1.56 2.73
LRU
49.75
51.11
LRUDA
51.36
52.39
2.01
GDSF
59.42
59.20
-0.37
Diference in the number of evictions produced in our simulator and Squid for the three selected replacement algorithms slightly differ from the emulated scenario. Deviations depend on the comparing algorithm. LFUDA has smaller deviations, never surpassing 1.4%; LRU deviations are always less than 2.6%; finally GDSF is the one offering worse deviations, but even in this case, deviations are by about 5%. The reason of these deviations is due to differences on the accuracy in the time-stamp aging mechanism mentioned above. As expected the time needed to obtain results is much shorter in the simulation environment than in the real scenario. Simulation time ranges from 3 to 5 minutes for the LRU and GDSF algorithm, while in the LFUDA algorithm takes by about half an hour. In the other hand, real scenario experiments are performed in no less than 10 hours. Notice that simulation times with respect to the real system depends depend on both, the algorithm and the trace length. Therefore, both speed and precision reached encourage us to use our framework to model web cache management techniques.
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
8. Conclusions In this paper we have presented a Proxy web cache simulator, coded in a modular way using classes in C++, which allows accurate and fast simulation of proxy cache management techniques. In addition, the tool provides a large variety of metrics and statistics for performance comparison purposes. We compare our open source web cache simulation framework comparing it with implementations of replacement algorithms used in a real proxy cache. In the process, the real proxy cache was adapted and all its replacement algorithms supported were modeled in our framework to compare performance. Several real traces were selected, filtered and replayed obtaining metrics that allow us to succeed in our task. Our tool performs very close to real systems. Proxy cache hit ratio never deviates more than 3.42% and object evictions never surpass 5%, even when the selected replacement algorithms included aging mechanisms with particularities not easy to reproduce. In addition, simulation speed obtained permits us to implement and study new caching management techniques in a fast and easy way. For example, to replay one of the logs using our simulation environment it ranges from 3 minutes to half an hour; depending on the replacement algorithm selected. Therefore confidence and speed is obtained for proposing and studying new caching management techniques with this environment. Now, we plan to address our research to design proxy cache management techniques using multiple cache structure that permit us to take advantage of the web object characteristics (size, popularity, frequency of use, ...) in order to reduce the user perceived latency.
References [1] M. Arlitt, L. Cherkasova, J. Dilley, R. Friedrich, and T. Jin, “Evaluating Content Management Techniques for Web Proxy Caches”, ACM SIGMETRICS Performance Evaluation Review, 4, 3-11, 2000. [2] O.Bahat, and A. Makowski, “Optimal replacement policies for non-uniform cache objects with optional eviction”, Proceedings of the 22nd Joint Conference of the IEEE Computer and Communications Society (INFOCOM 2003), San Francisco, USA, 2003. [3] C. Brabrand, A. Møller, A, S. Olesen, and M.I. Schwartzbach, “Language-Based Caching of Dynamically Generated HTML”, WWW Journal,4-2002. [4] R. Caceres, F. Douglis, A. Feldmann, G. Glass, and M. Rabinovich, “Web Proxy caching: The Devil is in the Details”, SIGMETRICS Performance Evaluation Review, 261998.
[5] P. Cao, J. Zhang, and K. Beach, “Active Cache: Caching Dynamic Contents on the Web”, Proceedings of the 1998 IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (MIDDLEWARE 98), The Lake District, England, 1998. [6] P. Cao, Wisconsin Web Cache Simulator, http://www.cs.wisc.edu/~cao/, 1997. [7] L.G. Cárdenas, J. Sahuquillo, A. Pont, and J.A. Gil, “The Multikey Web Cache Simulator: a Platform for Designing Proxy Cache Management Techniques”, Proceedings of the 12th Euromicro Conference on Parallel, Distributed and Network based Processing, A Coruña, Spain, 2004. [8] L. Cherkasova, “Improving WWW Proxies Performance with Greedy-Dual-Size-Frequency Caching Policy”,HPL-9869R1, HP Labs: Computer Systems Laboratory, 1998. [9] B.D. Davison, “NCS: Network and Cache Simulator -- An Introduction”, T.R.. DCS-TR-444, New Jersey, USA, Rutgers University, Department of Computer Science, 2001. [10] B.D. Davison, “HTTP Simulator Validation Using Real Measurements: A Case Study”, Proceedings of the 9th IEEE International Symposium on Modeling, Analysis and Simulation on Computer and Telecommunication Systems, Cincinnati, USA, 2001. [11] J. Dilley, and M. Arlitt, “Improving Proxy Cache Performance: Analysis of Three Replacement Policies”, IEEE Internet Computing, 6-1999. [12] F. Douglis, A. Haro, and M. Rabinovich, “Exploiting result equivalence in caching dynamic web content”, Proceedings of 2nd USENIX Symposium on Internet Technologies and Systems. Boulder, USA, 1999. [13] A. Feldmann, R. Cáceres, F. Douglis, G. Glass, and M. Rabinovich, “Performance of Web Proxy Caching in Heterogeneous Bandwidth Environments”, Proceedings of 18th Conference of the IEEE Computer and Communications Society, New York, USA, 1999. [14] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2616, 1999. [15] R.Rivest, R, “The MD5 Message Digest Algorithm”, RFC 1321, 1992. [16] Squid Web Proxy Cache Documentation. [17] W.Shi, E. Collins, and V. Karamcheti, “Modeling Object Characteristics of Dynamic Web Content”, Journal of Parallel and Distributed Computing (JPDC) special issue on scalable Internet services and architecture, 63-2003. [18] B. Smith, A. Acharya, T. Yang, and H. Zhu, “Exploiting result equivalence in caching dynamic web content”, Proceedings of 2nd USENIX Symposium on Internet Technologies and Systems, Boulder, USA, 1999. [19] C. Yuan, Z. Hua, and A. Zhang, “Proxy+: Simple Proxy Augmentation for Dynamic Content Processing”, Proceedings of 8th International Workshop on Web Content Caching and Distribution (WCW 2003). Hawthorne, USA, 2003.
Proceedings of the 10th IEEE Symposium on Computers and Communications (ISCC 2005) 1530-1346/05 $20.00 © 2005 IEEE
