limited than when caching HTML documents that are usually kept on disk. As indicated by .... Also, overlapping object hierarchies do not necessarily have the ...
Replacement Policies for a Distributed Object Caching Service Hilla Atzmon, Roy Friedman, and Roman Vitenberg Computer Science Department, The Technion, Haifa 32000, Israel. {atzmonh,roy,romanv}@cs.technion.ac.il
Abstract. This paper investigates replacement policies for an object caching service. The replacement policies studied include several previously known schemes, as well as a couple of new schemes that take into account the hierarchical structure of the caching service. Three metrics are used in comparing the replacement policies: cache hit rate the percentage of requests that were answered from the cache, byte hit rate - the percentage of bytes in replies that were answered from the cache, and access time - average time a client request has to wait for the corresponding reply. Also, unlike most works on cache replacement, this work examines the behavior of the entire system, rather than looking at a single cache at a time. Keywords: Object Caching, Cache Replacement Policies, CORBA
1
Introduction
One of the main goals of modern middlewares, such as CORBA [15] and .NET [16], is to facilitate the design of interoperable, extensible and portable distributed systems. This is done by standardizing a programming language independent Interface Definition Language (IDL), a large set of useful services, a generic inter Object Request Broker (ORB) communication protocol (GIOP/IIOP in the case of CORBA and SOAP in the case of .NET), and bridges to other common middlewares. Such middlewares combined with the global connectivity of the Internet, create a potential for truly global services that are available for clients anywhere in the world. However, the long and unpredictable latencies of the Internet as well as its unreliability, complicate the realization of this potential. In particular, the difference in response time for accessing objects spread over the Internet might be dramatic, regardless of the middleware and ORB being used. Moreover, the scalability of such services is likely to be limited by the relatively high communication overhead imposed on servers exporting the services. These can adversely affect the end-user experience, rendering such services unreliable and therefor useless for practical purposes.
This work was supported by the Israeli Ministry of Science and Technology grant number 1230 and by Technion VPR funds.
R. Meersman, Z. Tari (Eds.): CoopIS/DOA/ODBASE 2002, LNCS 2519, pp. 661–674, 2002. c Springer-Verlag Berlin Heidelberg 2002
662
H. Atzmon, R. Friedman, and R. Vitenberg
As in other areas of computer science, caching can be used to improve availability, predictability, and scalability of distributed services offered through middlewares. Specifically, accessing a copy of an object that is cached near the client is much faster than accessing a far away object. Moreover, shorter connections have lower chances of getting congested and fail, and thus accessing a local copy is more likely to succeed and behave in a predictable manner. Finally, if most client requests are handled by caches, fewer requests will reach the server, and thus the system as a whole will be able to handle more concurrent client requests. Since the cache size might be limited, we may need to use cache replacement, as done in many Web caching systems. Moreover, unlike Web caching, in our case we maintain objects in memory, and thus the cache size is much more limited than when caching HTML documents that are usually kept on disk. As indicated by Web caching studies, the exact cache replacement policy can have a significant effect on the cache performance. In this paper, we investigate several cache replacement policies for a distributed objects caching service. We compare these policies using three metrics: hit rate - the percentage of all requests that are served from the cache; byte hit rate - the percentage of bytes in replies that are served from the cache; and access time - the average time that a client waits between issuing a request and receiving a reply. Note that byte hit rate is important, since many wide area networks have limited bandwidth. Thus, in such settings, the byte hit rate may be a more significant performance factor than the hit rate. As for access time, this is the bottom line from the client’s point of view, since this is what the client notices. As can be seen from the results of this work, having the highest hit rate, or even highest byte hit rate, does not necessarily mean having the shortest access time. This is due to the fact that misses may take longer to serve, based on where in the network they occur. Some of the policies we consider, including LRU [13], LFU-DA [4], SIZE [20], and GDSF [10], are known from Web caching studies. Additionally, we introduce and explore a couple of new replacement policies, that we nicknamed HBASED and LFU-H-BASED, which take into account the hierarchical nature of the caching service that we use in this study. More specifically, all our measurements are conducted on the CASCADE system [11], which is a caching service for active CORBA objects, i.e., objects that include both data and code. CASCADE employs an update-based scheme to synchronize objects. An important aspect of CASCADE is that it dynamically builds a hierarchy for each cached object based on clients’ access pattern, as described in Section 2. As described in more detail in Section 3.2, the H-BASED policy takes into account, when deciding which object to evacuate, the position of cached object in its hierarchy, in order to reduce the overall access time. The LFU-H-BASED policy combines the benefits of LFU-DA and H-BASED, and is designed to optimize both the hit rate and access time of the system. The results of these experiments suggest that for a completely random trace, the SIZE policy performs best when considering hit rate. For traces that were generated by a workload generator, frequency and recency based policies like
Replacement Policies for a Distributed Object Caching Service
663
LFU-DA and LRU perform best when considering hit rate and byte hit rate. The new policies, H-BASED and LFU-H-BASED, improve the average access time in many cases.
2
CASCADE
This section briefly describes CASCADE, the caching service we use in this work. It appears here for the sake of completeness. More details about CASCADE can be found in [11]. CASCADE is a generic caching service for CORBA objects, supporting caching of active objects, which include both data and code. Caching objects without code either entails using the pre-defined confined set of possible operations or requires the code to be distributed over all the sites that can potentially keep a cached object copy. In the former case, generality is restricted. In the latter case, caching cannot be deployed in large scale dynamic environments. CASCADE allows to distribute object code dynamically upon request. Code caching also enables to preserve the standard CORBA programming model: The application works with the cached copy through the same interface it would have worked with the original object. In addition, all object methods (including updates) can be invoked locally, often eliminating the need to contact the remote object. CASCADE is highly configurable with regard to a broad spectrum of application parameters. It allows client applications to fully control many aspects of object caching, by specifying a variety of policies for cache management, consistency maintenance, persistence, security, etc. CASCADE is specifically designed to operate over the Internet by employing a dynamically built cache hierarchy. The caching service is provided by a number of servers, each of which is responsible for a specific logical domain. In practice, these domains can correspond to geographical areas. The servers are called Domain Caching Servers (DCSs). Cached copies of each object are organized into a hierarchy. A separate hierarchy is dynamically constructed for each object. The hierarchy construction is driven by client requests. The construction mechanism ensures that for each client, client’s local DCS (i.e., the DCS responsible for the client’s domain) obtains a copy of the object. In addition, this mechanism attempts to guarantee that the object copy is obtained from the nearest DCS having a copy of this object. This feature dramatically reduces response time and contributes to the scalability of the system. Once the local DCS has an object copy, all client requests for object method invocation go to this DCS, so that the client does not have to communicate to a far server. The DCS that holds an original object becomes the root for this object cache hierarchy. It plays a special role in building the hierarchy and in ensuring consistency of the cached copies. Hierarchies corresponding to each object are superimposed on the DCS infrastructure: Different object hierarchies may overlap or be completely disjoint. Also, overlapping object hierarchies do not necessarily have the same root.
664
H. Atzmon, R. Friedman, and R. Vitenberg
The hierarchy construction protocol, as described in [11], guarantees that for each client there is a local DCS that has a cached copy of the object; the local DCS handles the client’s requests. It is this fact and the hierarchical architecture of the system that allow to significantly reduce the response time, to distribute the load on DCSs and to render the caching service scalable. 2.1
Cache Management in CASCADE
Cache Manager Module. The cache manager controls insertion/deletion of objects to/from the object cache. There is one manager per DCS. The manager uses a configurable replacement policy in order to decide which object is to be evacuated from the cache, when a cache does not have enough space for a new copy of an object. When the manager is created, the policy to be used is determined. A different policy can be used for each DCS, but once it is determined for a specific DCS, it will not change. Each time an object is to be inserted to a cache, the manager first calculates the object’s size, checks whether there is enough space in cache, evacuates objects from cache if necessary, and maintains the structures used for the chosen replacement policy. When evacuating an object from a cache, the manager notifies the object itself, so it can perform some last actions, such as releasing unnecessary memory, and is then evicted. Object Evacuation and Reconstruction. In CASCADE’s model, a client has to explicitly de-register an object from its local DCS. As long as the object was not de-registered, the client is likely to access the object again. Thus, when a DCS decides to evict an object, it does not completely forget about it. Instead, the evicting DCS keeps a small record of the object’s identity and hierarchy, and uses it to disseminate requests and replies along that hierarchy. However, the memory that holds the object’s state is released. If some previously evacuated object is required later by a client, it will be acquired again from the parent node transparently to this client. In turn, if the parent node also does not have a copy of the requested object, it will try to acquire it from its parent node. This way the request ascends all the way up along the hierarchy until the DCS that has a copy of the object is reached. In the worst case, the chain reaches the root of the hierarchy. The object copy then descends along the hierarchy back to the request originator.
3 3.1
Replacement Policies Known Replacement Policies
Below we describe the main policies that were introduced in the past and were used in our study, due to the fact that in the previous Web caching studies they achieved better results than other policies. We then also briefly mention other known replacement policies.
Replacement Policies for a Distributed Object Caching Service
665
Least Recently Used (LRU) replaces the document in the cache that was not accessed for the longest period of time. The basic premise behind the LRU algorithm is that documents that have been referenced in the recent past will likely be referenced again in the near future. This property is known as temporal locality. The LRU algorithm is usually employed in disk block caches. It is justified by the temporal locality that commonly exists in file I/O request streams. SIZE removes largest files first [20]. It tries to maximize hit rate by replacing one large document instead of many small ones. This naturally reduces the number of future cache misses. In this study we also used the INVERSE(SIZE) policy, which removes the smallest file first. The main goal in using this policy is the comparison of SIZE and its inverse policy. GreedyDual-Size with Frequency (GDSF) is a hybrid policy, that combines in its decisions the recency of accesses, the cost of bringing an object to the cache, the object’s size, and the frequency in which it was accessed with some aging mechanism [10]. It improves the basic GreedyDual algorithm [21] that only combined recency and cost, and the GD-Size algorithm that combined recency, cost, and size. The idea is as follows: The mechanism attaches a key to each object, which is updated dynamically, and whenever there is not enough room in the cache, the object with the lowest key is removed. The key of each object is initialized when the object is inserted into the cache as the cost of bringing the object to the cache. Additionally, the mechanism uses an inflation factor variable denoted by L, which is initialized to 0. Then, each time an object is accessed, its key is being updated by: Ki = (Ci /Si ) ∗ Fi + L where Ci is the object’s cost, Si is its size, Fi is its frequency. Further, whenever an object with key k is evacuated, L is set to k. Least Frequently Used with Dynamic Aging (LFU-DA) is an improvement of the basic Least Frequently Used (LFU) policy, which employs an automatic aging mechanism. That is, LFU simply replaces the object that was least accessed. The problem with this is that if there are bursts of accesses to some object, that object builds a very large frequency counter, and is thus never replaced, even if it is no longer being accessed. An aging mechanism periodically reduces the frequency count of each object, thereby avoiding this problem. Similarly to GDSF, instead of a simple frequency count, LFU-DA attaches a key ki to each object i, and updates this key to Ki = Ci ∗ Fi + L (L is the same inflation factor as in GDSF) whenever the object is accessed. Other Known Techniques. LRU-MIN and LRU-THOLD are two variants of LRU that were investigated in [2], which also investigated the FIFO policy. log2 (SIZE) is a variant of SIZE that was introduced in [20]. Frequency Based Replacement (FBR) was proposed in [19]. It is a hybrid replacement policy, which attempts to capture the benefits of both LRU and LFU. Other forms of LFU that were introduced in the past include LFU-Aging, LFU*, and LFU*Aging [7].
666
3.2
H. Atzmon, R. Friedman, and R. Vitenberg
New Replacement Policies
In the first new policy, called H-BASED, replacement decisions are based on the hierarchy construction of the objects. For each object in the hierarchy, the replacement key is the number of direct descendants it has that were evacuated from cache. That is, when the cache is full, the cache manager will evacuate the object with the smallest key. The motivation behind this policy is to reduce access time. When an evacuated object is referenced, the object is reconstructed. Reconstruction is time consuming, since it involves requesting the copy from the parent node. This request can ascend all the way up along the hierarchy, after which the copy will descend down the hierarchy. The more evacuated descendants an object has, the chance that one of them will be referenced is bigger. In order to save access time, it is worthwhile to keep this object in the cache. An example for a replacement decision of the H-BASED policy is depicted in Figure 1. In this example, there are a couple of subtrees that are part of two larger hierarchies for Objects X and Y . Each node in a subtree is a copy of an object that resides in a different DCS. The shaded nodes represent valid copies. The white nodes represent objects that were evacuated from cache. Assume that the roots of these subtrees reside in the same DCS, and one of them has to be evacuated. Object y has four direct descendants that were evacuated from cache, while object x has two. According to the H-BASED policy, x will be evacuated from cache. It is worthwhile to keep y in the cache since there is more chance that one of the direct descendants of y will ask for a copy from its parent.
Fig. 1. H-BASED example
The second policy, called LFU-H-BASED, combines the LFU-DA and HBASED policies, in order to combine the benefits of both. As discussed above, with LFU-DA, each object in the cache is associated with a priority key. When an object is to be removed from cache, the one with the lowest key is removed. If there are several objects whose key is equal to the lowest key, one of them is chosen according to the secondary key. The secondary key in this case is the key used in H-BASED. We used LFU-DA as a primary key in the LFU-H-BASED since LFU-DA performs better than the other policies we investigated.
4 4.1
Performance Measurements The Environment
We have conducted the experiments using CASCADE, by playing artificially generated client access traces, as described below, on a system consisting of 10
Replacement Policies for a Distributed Object Caching Service
667
DCSs. The DCSs, as well as the clients, were run on Windows 2000 powered Intel based Dual 1.7 GHz Pentium 4 Xeon with 1G RDRAM. The network connecting the DCSs was a 100 Mbps Fast Switched Ethernet, but we emulated a general Internet topology by inserting artificial delays on invocations between DCSs that are proportional to the size of messages sent. The traces played on the system consisted of clients issuing the following types of requests: registration and subscription. A registration request is used to register a new object into one of the DCSs, which also creates a new hierarchy for this object. After registering, the client always performs one read and one write operation on the new object. In a subscription request, the client asks for a reference for an object from a specific DCS. If the DCS is not part of the requested object’s hierarchy, it joins the hierarchy at this point. Once the DCS becomes part of the hierarchy, it returns a reference for the object to the client. After receiving the reference, the client always performs one read and one write operation. As the trace proceeds, hierarchies are built and objects are cached. 4.2
Trace Generation
The main parameters for generating a trace are the number of servers, number of original objects, sizes of objects, number of requests, objects popularity, order of requests, and correlation between objects and servers in the request itself. We have generated four traces, one of which is completely random, and the others based on a trace generator, called ProWGen [9], that allows inducing more sophisticated distributions, and correlations between the various emulation parameters. All our traces included 10 servers and 1,000 objects, and start by issuing 1,000 registration requests, one for each object, followed by a total of 20,000 subscription requests distributed among the DCSs and objects. In the random trace, object sizes, the order of requests to objects, and the correlation between objects and servers are chosen in random using uniform distribution. In the following subsection, we describe the various ProWGen parameters, what was their setting in each of the traces, and how we adapted traces generated by ProWGen to our needs. ProWGen. ProWGen incorporates five selected workload characteristics, which are one-time referencing, file popularity, file size distribution, correlation between file size and popularity, and temporal locality. In our experiments, we used 50-70% one-time referencing, which corresponds to results from Web caching studies, a value of β = 0.75 in the Zipf-like distribution [17] that controls the file popularity [4,3,8,14,18], and zero correlation between file size and popularity. File size distribution is modeled in ProWGen using lognormal distribution with a tail modeled with a Pareto distribution [1,5,6,12]. The file size distribution and temporal locality are the main parameters that distinguish among the tests we performed, as outlined below. Each reference in the workload generated by ProWGen is a two-tuple consisting of a file id followed by a file size. In order to make the traces applicable
668
H. Atzmon, R. Friedman, and R. Vitenberg
for CASCADE, we mapped these generated workloads to a workloads of CASCADE requests, as follows: Each distinct file id is mapped to a distinct object name. Each reference in the original workload is translated into a subscription request for that object. The target of the request is chosen randomly from the 10 DCSs initiated for that run. At the beginning of the run, registration requests are initiated for all distinct objects. The target of each registration request is chosen randomly as well. We used three different ProWGen traces in our experiment. The differences between the traces refer to the amount of one-timers and to the body of the size distribution. In Trace 1, one-timers make 70% of the distinct objects, resulting in 700 one-timers out of 1,000. The range of object sizes is 0-24K, while the lognormal distribution of the sizes has a mean value of 7000 and standard deviation of 11,000, which creates a wide body. In Trace 2, one-timers consist 50% of the distinct objects, resulting in 500 one-timers out of 1,000. The range of sizes is 0-50K, while the lognormal distribution has a mean value of 2,000 and standard deviation of 2,500, meaning many small objects. Trace 3 is the same as Trace 2, except for the lognormal distribution: Trace 3 is generated with mean value of 2,000 and standard deviation of 1,000, meaning many intermediate sized objects. 4.3
Results
Random Trace Results. Figure 2 exhibits the results of all seven replacement policies, for cache sizes ranging from 30 KB through 7680 KB. As can be seen, SIZE outperforms all other policies when considering the hit rate metric. All other policies perform roughly the same, except for INVERSE(SIZE) which is the worse. Since the trace is random, there is no locality effect, and therefore the only differentiating factor is the size of objects. It can also be seen that no policy outperforms another when considering the byte hit rate metric. Since SIZE prefers to keep in the cache many small objects, the amount of bytes it satisfies in a hit is small. This is the reason that the byte hit rate of SIZE is similar to the other policies, despite that fact that its hit rate is better. INVERSE(SIZE) has the opposite behavior. It has the biggest miss rate, but since it keeps large objects in cache, every hit returns a large amount of data. The results in Figure 2 indicate that H-BASED has the best access time, which was expected, given the discussion in Section 3.2. INVERSE(SIZE) performs worst, since its hit rate is substantially poorer than the others. ProWGen Traces Results. Figure 3 shows the average hit rate obtained for the three ProWGen traces. In all of them LFU-DA, LFU-H-BASED and LRU outperform the other policies. In Traces 1 and 3, GDSF is the next best policy. In Trace 2, SIZE is very similar to GDSF. The reason is that in Trace 2 there are many small objects, and SIZE keeps many of them in cache instead of large objects. H-BASED performs worse than GDSF with small caches, but performs the same as GDSF for bigger caches. INVERSE(SIZE) performs worst, as expected.
Replacement Policies for a Distributed Object Caching Service
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED
90
80
70
hit rate
60
50
40
30
20
10
0
0
30
60
120
240 480 cache size (kb)
960
1920
3840
7680
120
240 480 cache size (kb)
960
1920
3840
7680
120
240 480 cache size (kb)
960
1920
3840
7680
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED
90
80
70
byte hit rate
60
50
40
30
20
10
0
0
30
60
250
200
access time
150
100
LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED
50
0
0
30
60
Fig. 2. Random Trace
669
H. Atzmon, R. Friedman, and R. Vitenberg
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED ProWGen Trace 1
90
80
70
hit rate
60
50
40
30
20
10
0
0
30
60
120
240 cache size (kb)
480
960
1920
3840
60
120
240 cache size (kb)
480
960
1920
3840
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED ProWGen Trace 2
90
80
70
hit rate
60
50
40
30
20
10
0
0
30
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED ProWGen Trace 3
90
80
70
60
hit rate
670
50
40
30
20
10
0
0
30
60
120
240 480 cache size (kb)
960
1920
Fig. 3. ProWGen Traces Hit Rate
3840
7680
Replacement Policies for a Distributed Object Caching Service
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED ProWGen Trace 1
90
80
70
byte hit rate
60
50
40
30
20
10
0
0
30
60
120
240 cache size (kb)
480
960
1920
3840
60
120
240 cache size (kb)
480
960
1920
3840
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED ProWGen Trace 2
90
80
70
byte hit rate
60
50
40
30
20
10
0
0
30
100 LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED ProWGen Trace 3
90
80
70
byte hit rate
60
50
40
30
20
10
0
0
30
60
120
240 480 cache size (kb)
960
1920
3840
Fig. 4. ProWGen Traces Byte Hit Rate
7680
671
H. Atzmon, R. Friedman, and R. Vitenberg
350
300
access time
250
200
150
ProWGen Trace 1
100
LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED
50
0
0
30
60
120
240 cache size (kb)
480
960
1920
3840
60
120
240 cache size (kb)
480
960
1920
3840
350
300
access time
250
200
150
ProWGen Trace 2
100
LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED
50
0
0
30
350
300
250
access time
672
200
150
ProWGen Trace 3
100
LRU LFU−DA SIZE INVERSE(SIZE) GDSF H−BASED LFU−H−BASED
50
0
0
30
60
120
240 480 cache size (kb)
960
1920
3840
Fig. 5. ProWGen Traces Access Time
7680
Replacement Policies for a Distributed Object Caching Service
673
Figure 4 shows the average byte hit rate obtained for the three ProWGen traces. In all traces, LFU-DA and LFU-H-BASED outperform the other policies. Next is LRU, GDSF and H-BASED. SIZE and INVERSE(SIZE) perform the worst. The bad performance of SIZE can be explained by the fact that SIZE keeps small objects in cache. Thus, the number of bytes that are found in the cache, when using the SIZE policy, is relatively small. Figure 5 shows the average access time obtained for the three ProWGen traces. It can be seen that in most cases LFU-H-BASED improves the average access time achieved by LFU-DA. The largest improvement is in Trace 1: up to 35%. In Trace 2 the performance of LFU-H-BASED is the same as of LFUDA. In Trace 3 there is an improvement of up to 30%. The relative order of performance of the other policies is similar to the order seen by the average byte hit rate. LFU-DA has the lowest access time after LFU-H-BASED, LRU is next, followed by H-BASED and GDSF. SIZE is much worse since its byte hit rate is very low compared to the other policies. Low byte hit rate indicates that many bytes are being transferred through the network, which increases the average access time. INVERSE(SIZE) has the worst average access time, as both its hit rate and byte hit rate are very low.
5
Conclusions
This paper presented a performance study of replacement policies of an object caching service. The work investigated several known policies and a couple of new ones. Emulation of a real Internet wide distributed system was used in order to evaluate the performance of the policies. All experiments used CASCADE, a caching service for CORBA objects. Traces with different characteristics were generated. One trace was generated randomly and three traces were generated with the help of ProWGen, a synthetic workload generator. Our results show that performance of a policy in a specific experiment heavily depends on the trace being used. The results suggest that for a random trace, the SIZE policy performs best when considering hit rate, while all policies perform roughly the same when considering byte hit rate. The results of the traces generated by ProWGen indicate that frequency and recency based policies, like LFU-DA, LFU-H-BASED, and LRU have the best hit rate and byte hit rate. Also, while H-BASED did not achieve as good performance as we hoped, LFU-H-BASED managed to obtain the best average access time, while keeping the same good hit rate and byte hit rate as LFU-DA.
References 1. G. Abdulla, E. Fox, M. Abrams, and S. Williams. WWW proxy traffic characterization with application to caching. Technical Report TR-97-03, Computer Science Department, Virginia Tech., March 1997. 2. M. Abrams, C. Standridge, G. Abdulla, S. Williams, and E. Fox. Caching proxies: Limitations and potentials. In Proceedings of the Fourth International World Wide Web Conference, pages 119–133, Boston, USA, December 1995.
674
H. Atzmon, R. Friedman, and R. Vitenberg
3. V. Almeida, M. Cesario, R. Fonseca, W. Meira Jr., and C. Murta. Analysing the behavior of a proxy server in light of regional and cultural issues. In Proceedings of the Third International WWW Caching Workshop, Manchester, England, June 1998. 4. M. Arlitt, L. Cherkasova, J. Dilley, R. Friedrich, and T. Jin. Evaluating content management techniques for web proxy caches. Performance Evaluation Review, 27(4):3–11, March 2000. 5. M. Arlitt and T. Jin. A workload characterization study of the 1998 world cup web site. IEEE Network, 14(3):30–37, May/June 2000. 6. M. Arlitt and C. Williamson. Internet web servers: workload characterization and performance implications. IEEE/ACM Transactions on Networking, 5(5):631–645, October 1997. 7. M. Arlitt and C. Williamson. Trace-driven simulation of document caching strategies for internet web servers. Simulation Journal, 68(1):23–33, January 1997. 8. 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 1999, pages 126–134, New York, NY, March 1999. 9. M. Busary and C. Williamson. On the sensitivity of web proxy cache performance to workload characteristics. In Proceedings of IEEE INFOCOM 2001, pages 1225– 1234, Anchorage, Alaska USA, April 2001. 10. L. Cherkasova. Improving WWW proxies performance with greedy-dual-sizefrequency caching policy. Technical Report HPL-98-69R1, Hewlett-Packard Laboratories, November 1998. 11. G. Chockler, D. Dolev, R. Friedman, and R. Vitenberg. Implementing a caching service for distributed CORBA objects. In Proceedings of Middleware ’00, pages 1–23, April 2000. 12. B. Duska, D. Marwood, and M. Feeley. The measured access characteristics of world-wide-web client proxy caches. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, pages 23–35, December 1997. 13. J. Hennessy and D. Patterson. Computer Architecture – a Quantitive Approach. Morgan Kaufmann Publishers, 1990. 14. A. Mahanti, C. Williamson, and D. Eager. Traffic analysis of a web proxy caching hierarchy. IEEE Network, 14(3):16–23, May/June 2000. 15. OMG. The Common Object Request Broker: Architecture and Specification. OMG, 1995. 16. D. Platt. Introducing MicrosoftTM .NET. MicrosoftTM Press, 2001. 17. References on Zipf’s law. Available at http://linkage.rockefeller.edu/wli/zipf/. 18. C. Roadknight, I. Marshall, and D. Vearer. File popularity characterisation. ACM Sigmetrics Performance Evaluation Review, 27(4):45–50, March 2000. 19. J.T. Robinson and M.V. Devarakonda. Data cache management using frequencybased replacement. In Proceedings of the ACM SIGMETRICS Conference on Measurement and Modeling of Computer Systems, pages 134–142, May 1990. 20. S. Williams, M. Abrams, C.R. Standridge, G. Abdulla, and E.A. Fox. Removal policies in network caches for World-Wide Web documents. In Proceedings of the ACM SIGCOMM’96 conference, pages 293–305, Palo Alto, CA USA, August 1996. 21. N. Young. On-line caching as cache size varies. In Proceedings of the second annual ACM-SIAM symposium on Discrete algorithms, pages 241–250, San Francisco, CA USA, January 1991.
