1 ENHANCHING THE WEB’S INFRASTUCTURE: FROM CACHING TO REPLICATION ECE 7995 Presented By: Pooja Swami and Usha Parashetti
2 Contents Introduction Issues to be addressed Caching on the Web Issues with Web Caching Design Performance study of Web Caching Deficiencies of Web Caching Caching goes Replication Implementation of Replication Web location and information service (WLIS) Performance study of CgR Conclusion
3 Introduction Enormous Success of the Internet has increased the number of people getting added to the WWW. User’s of WWW have increased exponentially. Increased use of WWW has created problems within the Internet Increased latency over the web due to insufficient bandwidth Network gets congested due to increased traffic Servers get overloaded with request due to increased traffic Solutions to these problems Introduce Caching on the Web Using Caching Proxies Introduce Replication Increase the availability of data by creating mirrored sites Combine the benefits provided by both Caching and Replication Use of active caching scheme such as CgR
4 Issues to be addressed to enhance web’s Infrastructure To preserve the usability of the WWW, the following issues need to be addressed at the server level Document retrieval latency times must be decreased Document availability must be increased, perhaps by distributing documents among several servers The amount of data transferred must be reduced Network access must be redistributed to avoid peak hours.
5 Caching on the web is implemented using Caching proxies. A proxy acts as a mediator between the user’s machine and the outside world. From the user’s point of view, the proxy acts as a Web server: each request is sent to and answered by the proxy. From the server’s point of view, the proxy acts like a client: it forwards requests to the originating server. Data stored is shared among several users, so there is an increased probability of data being accessed more than once. Caching on the web
6 Current Issues in Web caching design Design of the replacement policy on the Web becomes complex If a cache is full when it receives a request to store a large document, then would it be more sensible to replace a single large document than several smaller ones. Needs to consider the best strategy to maximize caching benefits. Determination of the pattern of document access and the time required to reload data is more complicated on the Web Loading time of course depends on the origin of the document Data transferred over international links typically takes longer to retrieve than information from servers in the same country Caching strategies face with the problem of document staleness on the Web When a cached document changes on the originating server, caching proxies are not aware of the changes. Further requests satisfied from the cache will deliver out-of-date information Causes the problem of cache coherency
7 Current Issues in Web caching design (contd..) Web caching proxies can employ time-to-live,TTL to estimate document staleness TTL Implementation procedure A date of last modification is included in every reply from a Web server A TTL timing window based on that date is associated with each document put in the cache On document requested, the proxy checks the timing window. A request occurring within the TTL time frame is served directly from the cache, the assumption being that the document is still current A request occurring after the TTL has expired causes a conditional reload to be performed Originating server will answer either with the new document or a special reply indicating unchanged data
8 Performance Study of Web Caching Locality of reference and the web A very small subset of pages were frequently accessed, while most documents were accessed relatively seldom. On averaging cache hit rates it was found that 14 % of all cached pages were responsible for 42 % of the data served directly from the cache, which occupied only 7% of the overall disk space. Study results indicates that locality of reference exists with respect to web
9 Performance Study of Web Caching (contd..) Performance gains observed in terms of Cache hit rates, Byte hit rates and Transferred data. Theoretically achievable hit rates calculated are to be : Cache hit rate : 56.5% Byte hit rate : 40.6 % Transferred data :3,650,950,731 bytes Practical results obtained were : Cache hit rate : 21.3 % Byte hit rate : 16.6 % Transferred data :4,992,987,253 bytes Study results indicate that only 40 % of the theoretically possible hit rate is achieved
10 Deficiencies of Web Caching Caching alone cannot provide complete solution towards improvement of Web Infrastructure Document retrieval latency times Caching provides only partial solution to this problem Performance study indicate 69.9 % of the pages were retrieved only once Document availability Not possible to check if the document requested is current, in case when originating server is down Reduction in data transfer Caching cannot reduce the amount of data transferred for the documents retrieved only once Redistribution of Network access Caching cannot solve this problem Document loading and staleness checks are made in the critical path at the time of request
11 Caching goes Replication The concept of CgR is to combine caching and replication to achieve the goal mentioned earlier. The basic idea is that of an active caching scheme in which servers can decide which documents should be held where. Its simply transforming the caching servers into replicate servers.
12. Describing the current Web with CgR, caches now become active replicates for certain URL namespaces of some of those servers whose data previously only cached.. Primary server will have to know only the set of its direct replicates. Level 1 replicate servers can in turn have replicates(RS4 and RS5) for which they act as a primary server.. Conversion of caches to Replicated Servers (RS) and conversion of normal WWW servers to Primary Servers (PS), is the central concept of CgR.. The selection of which caching servers to convert to replicate servers can be done manually or automatically based on appropriate heuristics.
13 How replication is implemented Servers initiate propagation by sending a normal HTTP GET request bearing a specific notification to their replica sites. CgR-enhanced replicate servers will interpret this notification as a command to request the data to be replicated. Basic issue is how the client will be able to select replicate servers. This can be done by the use of a CgR-enhanced client-side proxy (CP) CP permits all the action to be performed transparently without modifying the clients or their interface to the Web. Users only has to choose this proxy as their gateway to the internet.
14 How replication is implemented cont. Now CP can directly send HTTP requests to replicate as well as conventional servers. CP may switch RS anytime for load balancing. CP offers only a basic means by which clients can address a group of servers. What still needed is a way to propagate information about the replicate servers that exist and what data they hold.
15 Web location and information service (WLIS) WLIS keeps track of which URL namespaces are replicated and which servers belong to logical groups of primary server and replicate servers. A natural place to implement the WLIS service is the client-side proxy, but can also be included in the primary server or offered by separate WLIS servers. Now the question arises about the creation of WLIS information, since it can’t be entered manually into the system that is meant to be highly scalable.
16. This fig. shows how the distributed WLIS database is set up.. Assuming that initially no WLIS information is available, the CP will forward requests directly to the PS (Step 1).. PS knows about its first-level replicate servers (RS1-RS3) and will include this information in its reply.. The client receives this initial WLIS information and stores it for later use. The next request can be redirected towards one of the RS indicated in the previous WLIS response.. If the decision is made to query the RS1, it will in turn reply with the requested document and a list of its own replicates (RS4 and RS5).
17 Performance study of CgR Cache Hit Rate: Cache hit rate for CgR-enhanced RS with different quotas of its cache assigned to hold replicated data. For small cache size, reserving a cache space for replicates decreased overall performance
18 Transmission times for document requests: Small cache sizes again relates to the lower cache hit rates. When the size are increased to 500 and 800, transmission time are reduced by about 1.5 percent.
19 Conclusion Caching and replication have proved beneficial in many areas of computing but advantages of the combination of these two approaches are manifold. They not only help to reduce the latency but also remedy the extreme variations of network bandwidth. Additionally they provide a more fault-tolerant and evenly balanced system.
20 Thank You