seminar on - school of information technology, iit kharagpur

22
2/2/2005 Web Caching 1 Seminar on By Sai Rahul Reddy P

Upload: others

Post on 03-Feb-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

2/2/2005 Web Caching 1

Seminar on

BySai Rahul Reddy P

2/2/2005 Web Caching 2

Topics covered …

1. Why Caching2. Advantages of Caching 3. Disadvantages of Caching 4. Cache-Control HTTP Headers 5. Proxy Caching6. Caching architectures7. Prefetching8. Cache Replacement Strategies9. Cache Coherence Mechanisms10. Dynamic Caching

2/2/2005 Web Caching 3

Why Caching• The World Wide Web is of an exponential growth in size, which results in network

congestion and server overloading (the size of static Web pages increases approximately 15 % per month).

• Additionally, each Internet data request from the end-user can lead to large and variable delays. Such slow response times make Internet use and E-commerce undesirable and impractical for the end- user.

http//www.research.digital.corn/SRC/whatsnew/sem.html).

2/2/2005 Web Caching 4

Advantages of Caching

1. Web caching reduces bandwidth consumption, thereby decreases network traffic and lessens network congestion.

2. Web caching reduces access latency due to two reasons: a) Frequently accessed documents are fetched from nearby proxy caches instead of

remote data servers, the transmission delay is minimized. b) Because of the reduction in network traffic, those documents not cached can also be

retrieved relatively faster than without caching due to less congestion along the path and less workload at the server.

3. Web caching reduces the workload of the remote Web server by disseminating data among the proxy caches over the wide area network.

4. If the remote server is not available due to the remote server's crash, the client can obtain a cached copy at the proxy. Thus, the robustness of the Web service is enhanced.

2/2/2005 Web Caching 5

Disadvantages of using a caching

1. The main disadvantage is that a client might be looking at stale data due to the lack of proper proxy updating.

2. The access latency may increase in the case of a cache miss due to the extra proxy processing. Hence, cache hit rate should be maximized and the cost of a cache miss should be minimized when designing a caching system.

3. A single proxy cache is always a bottleneck. A limit has to be set for the number of clients a proxy can serve. An efficiency lower bound should also be enforced.

4. A single proxy is a single point of failure.

5. Using a proxy cache will reduce the hits on the original remote server which might disappoint a lot of information providers, since they cannot maintain a true log of the hits to their pages. Hence, they might decide not to allow their documents to be cacheable

2/2/2005 Web Caching 6

HTTP 1.1GET / HTTP/1.1Host: mail.yahoo.comIf-Modified-Since:dateConnection:close

Typical HTTP 1.1 request Header

HTTP/1.1 200 OK Date: Fri, 30 Oct 1998 13:19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct 1998 14:19:41 GMT Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT ETag: "3e86-410-3596fbbc" Content-Length: 1040 Content-Type: text/html

Typical HTTP 1.1 response Header

2/2/2005 Web Caching 7

Cache-Control HTTP Headersmax-age=[seconds] — specifies the maximum amount of time that an representation will be considered fresh. Similar to Expires, this directive is relative to the time of the request, rather than absolute. [seconds] is the number of seconds from the time of the request you wish the representation to be fresh for. s-maxage=[seconds] — similar to max-age, except that it only applies to shared (e.g., proxy) caches. public — marks authenticated responses as cacheable; normally, if HTTP authentication is required, responses are automatically uncacheable. no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching. no-store — instructs caches not to keep a copy of the representation under any conditions. must-revalidate — tells caches that they must obey any freshness information you give them about a representation. HTTP allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules. proxy-revalidate — similar to must-revalidate, except that it only applies to proxy caches.

2/2/2005 Web Caching 8

What is cacheable ?

Objects that have a long freshness time,small in size and have high access latency (when fetched from the origin server) are the objects best suited for caching. The following objects cannot be normally cached.

Objects that are password-protected

Any URLs with /cgi-bin/ or any other pre-configured patterns (for example, if a URL contains ‘?’, it is indicative that the URL iscalling a program with the portion after the ‘?’ as its argument.)

Any file exceeding a pre-defined limit.

SSL requests, which are tunneled through and not cached.

2/2/2005 Web Caching 9

Proxy Caching

• Forward Proxy Caching • Reverse Proxy Caching • Transparent Proxy Caching

Router transparent Switch transparent proxy caching

2/2/2005 Web Caching 10

Caching architectures

• Hierarchical caching architecture (Figure)

Caches placed at different network levels: Client, Institutional, Regional, National.When a document is found it travels down the hierarchyProblems:

1) Additional Delays2) Higher Level Caches potential Bottlenecks3) Several Copies of Document Stored

• Distributed caching architecture (Figure)

No intermediate caches. Only Institutional Caches.Have mechanisms to share documents: ICP, CARP, Cache Digests (Ex)

2/2/2005 Web Caching 11

Prefetching

Why Prefetching ?Maximum cache hit rate can be achieved by any caching algorithm is usually no more than 40 % to 50%.

Prefetching can be applied in 3 ways

1. Between browser clients and Web servers2. Between proxies and Web servers3. Between browser clients and proxies

2/2/2005 Web Caching 12

Cache Replacement Policies

Traditional replacement policies and its direct extensions:

1. Least Recently Used (LRU): LRU evicts the object which was requested the least recently.

2. Lease Frequently used (LFU): LFU evicts the object which is accessed least frequently.

3. Pitkow/Recker Strategy: It evicts objects in LRU order, except if all objects are accessed within the same day, in which case the largest one is removed.

2/2/2005 Web Caching 13

Cache Replacement Policies

Key based Replacement Policies

1. LRU-MIN: If there are any objects in the cache which have size being at least S, LRU-MIN evicts the least recently used such object from the cache. If there are no objects with size being at least S, then LRU-MIN starts evicting objects in LRU order of size being at least S/2. That is, the object who has the largest log(size) and is the least recently used object among all objects with the same log(size) will be evicted first.

2. LRU-Threshold: It is the same as LRU, but objects larger than a certain threshold size are never cached.

3. Lowest Latency First: It minimizes average latency by evicting the document with the lowest download latency first.

2/2/2005 Web Caching 14

Cache Replacement PoliciesCost based replacement strategies

• Greedy Dual Size (GD-Size) Associates a cost with each object and evicts object with the lowest cost/size.

• Hierarchical Greedy Dual (Hierarchical GD)The function for an object i from server s depends on the following parameters: cs (time to contact server s), bs (available bandwidth to server s). The function is defined as

where Wb and Wn are weighting parameters. Estimates for cs and bsare based on the time to fetch documents from server s in the recent past.

2/2/2005 Web Caching 15

Cache Coherency Mechanisms

1. Strong Cache Consistency(a) Client Validation (b) Server invalidation

2. Weak cache consistency(a) Adaptive TTL(b) Piggyback Invalidation

-- Piggyback Cache Invalidation-- Piggyback Server Invalidation

2/2/2005 Web Caching 16

Dynamic Data Caching

• Active Cache

• Web server Accelerators

2/2/2005 Web Caching 17

Overview of Dynamic proxy caching system

2/2/2005 Web Caching 18

Conclusion

• Web service becomes more popular-- More network congestion-- More server overloading

• Web caching – one of the effective techniques• Caching Dynamic pages, cache routing, proxy

placement

2/2/2005 Web Caching 19

Hierarchical caching architecture

(Back)

2/2/2005 Web Caching 20

(Back)

2/2/2005 Web Caching 21

Example (Bloom Filters)• S = {14, 63, 57, 31}• m = 12 (i.e., 3 bits per key)• k = 3; h1(x) = (x + 1) mod 12; h2(x) = (3x + 2) mod 12;

h3(x) = (5x+3) mod 12

x h1 h2 h3

14 3 8 363 4 11 657 10 5 031 8 11 2

V0 1 2 3 4 5 6 7 8 9 10 111 1 1 1 1 1 11

2/2/2005 Web Caching 22

Example: Membership Test

0 1 2 3 4 5 6 7 8 9 10 111 1 1 1 1 1 1V 1

• Does 20 belongs to S?• Answer: h1(20) = (20 + 1) mod 12 = 9

(Back)