2.3 Hits, Misses, and Freshness

only for RuBoard - do not distribute or recompile

2.3 Hits, Misses, and Freshness

When a cache receives a request, it checks to see if the response has already been cached. If not, we say the request is a cache miss , and the request is forwarded on to the origin server. Cache misses occur for objects that have never been requested previously, objects that are not cachable , or objects that have been deleted to make room for new ones. It's common for 50 “70% of all requests to be cache misses.

If the object is present, then we might have a cache hit. However, the cache must first decide if the stored response is fresh or stale . A cached response is fresh if its expiration time has not been reached yet; otherwise , it's stale. Fresh responses are best because they are given to the client immediately. They experience no latency and consume no bandwidth to the origin server. I'll call them unvalidated hits . Stale responses, on the other hand, require validation with the origin server.

The purpose of a validation request is to ask the origin server if the cached response is still valid. If the resource has changed, we don't want the client to receive a stale response. HTTP also calls these conditional requests . The reply to a conditional request is either a small "Not Modified" message or a whole new response. The Not Modified reply, also known as a validated hit , is preferable because it means the client can receive the cached response, which saves on bandwidth. A validated miss , where the origin server sends an updated response, is really equivalent to a regular cache miss. We'll talk more about validation in Section 2.5.

How does the cache know whether an object is fresh or stale? HTTP/1.1 provides two ways for servers to specify the freshness lifetime of a response: the Expires header and the max-age cache control directive. The Expires header has been in use since HTTP/1.0. Its value is the date and time at which a response becomes stale, for example:

 Date: Mon, 19 Feb 2001 01:46:17 GMT 

Application developers find dates such as this awkward for a number of reasons. The format is difficult to parse and prone to slight variations (e.g., "Monday" instead of "Mon"). Additionally, absolute timestamps are susceptible to clock skew problems, when different systems have different notions of the current time. For these reasons, HTTP/1.1 includes a number of headers and directives that use relative instead of absolute times. The max-age cache control directive specifies the number of seconds that the response should be considered fresh, for example:

 Cache-control: max-age=21600 

This states that the response is fresh for six hours after it is generated. Section 13.2.3 of RFC 2616 describes how to calculate the age of a response.

Even though HTTP provides these two mechanisms, they are not used very often. Recent measurements suggest that less than 10% of all responses have an expiration time. In these cases, caches are free to apply local rules to estimate object freshness lifetimes (RFC 2616, Section 13.2.2). Most products have configuration options that give the administrator control over these objects. A conservative setting is always to validate responses that don't have an expiration time. Sites with poor connectivity are likely to use liberal settings that return such objects as hits without validation.

Many products also utilize an algorithm known as the last-modified factor (LM-factor). It is based upon the somewhat intuitive principle that young objects, because they have recently been created or changed, are likely to be changed soon. Similarly, old objects that have not changed for a long time are less likely to change soon. ^[5] An object's LM-factor is calculated as the ratio of the time since the object entered the cache to the object's age when it entered the cache. The object is presumed to be fresh so long as its LM-factor remains below some threshold, which is typically a configurable parameter. If the threshold is 0.2, for example, an object that is 10 days old when it enters a cache remains fresh for the following 2 days. On the first request after two days have passed, the object is validated with the origin server. If the object is still valid (not modified), the timestamps are updated. In this case, the age when entering becomes 12 days, and the age since entering becomes 0. Now, it remains fresh for the following 2.4 days. Most caching products allow you to set different threshold values for different types of objects.

^[5] Unfortunately, just the opposite is true for objects updated at fixed intervals (e.g., hourly or daily). As they get older, they are more likely to be updated.

You might find it strange that a cache sometimes returns a hit without validating it first. Given the option, wouldn't it be better to always make sure the user receives absolutely up-to-date information? Unfortunately, it isn't that simple. The penalty you pay for cache consistency is higher latency. In general, validation requests take a significant amount of time compared to simply returning unvalidated hits. If a cache's fresh versus stale predictions are accurate, the latency reductions are a big win. By tuning the cache configuration, namely the LM-factor thresholds, you should be able to find an appropriate balance in the tradeoff between low latency and cache correctness.

HTTP/1.1 allows caches to intentionally return stale responses in some cases. For example, a cache that tries to validate a response, but cannot connect to the origin server, may return the stale response rather than no response at all. The RFC acknowledges that some caching proxies operate under severe bandwidth constraints, and that these may be configured to return stale responses rather than attempt a validation request.

Clients can also indicate their willingness to accept stale responses with the max-stale cache control directive. This directive can be used with or without a numeric value, for example:

 Cache-control: max-stale 

means the client will accept a cached response no matter how stale. On the other hand:

 Cache-control: max-stale=7200 

means a response that has been stale for 7200 seconds (two hours) or less can be sent to the client without validation.

HTTP/1.1 does not give caches or clients the final say in stale responses. The must-revalidate and proxy-revalidate cache control directives override the cache and client preferences regarding staleness. A response containing this directive must always be validated when it becomes stale. According to RFC 2616, origin servers should use this feature "if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction." proxy-revalidate applies only to shared (proxy) caches, while must-revalidate applies to all caches.

Whenever a cache returns a stale response for any reason, it must include the following Warning: header:

 Warning: 110 Response is stale 

User- agents , in turn , are supposed to alert users when they receive a response with a Warning: header.

only for RuBoard - do not distribute or recompile