Output caching is a powerful technique that increases server application throughput by caching the content generated from dynamic pages. Output caching is enabled by default, but output from any given response will not be cached unless explicit action is taken to make the response cacheable.
<p>
In order to make a response eligible for output caching, the response needs to have a valid expiration/validation policy and public cache visibility. The output cache only respects the HTTP GET and HEAD methods. When a request is received for a cached page using a POST method, the dynamic content must be generated explicitly rather than satisfying the request from the output cache.
<p>
The output cache also supports caching GET methods with query strings, comparing the query strings for identity. This means that requests with identical key/value pairs presented in a different orders will be treated as cache misses.
<p>
The output cache respects the expiration and validation policies for pages. If a page is in the output cache and the developer has marked it with an expiration policy that indicates that the page expires 60 minutes from the time it's cached, the page is removed from the output cache after 60 minutes. If another request is received after that time, the page code is executed and the page can be cached again.
<p>
The sort of expiration described above is called <b>absolute expiration</b> -- a page is valid until a certain time. The output cache also supports a type of expiration known as <b>sliding expiration</b>, which indicates that a page should be cached for a given time after its last access. As an example, consider a page that has a sliding expiration policy indicating that the page is to be cached for 30 minutes after its last request. The page is requested, causing it to be cached, and then is requested many more times in rapid succession--these requests are all satisfied from the cache. Finally, no more requests arrive for at least 30 minutes and the page is removed from the output cache. The next request received for the page will cause the page code to be executed again.
<p>
The following example demonstrates a simple way to output cache responses using the <%@ Output Cache %> directive. The example simply displays the time when the response was generated. To see output caching in action, invoke the page and note the time at which the response was generated. Then hit refresh and note that the time has not changed, indicating that the second response is being served from the output cache.
The directive used to activate output caching on the response is:
<div class="code"><pre>
<%@ OutputCache Duration="60" %>
</pre></div>
which simply indicates that the page should be cached for 60 seconds. Requests received while the page is still cached will be satisfied from the cache. After 60 seconds, the page will be removed from the cache and the next request will be handled explicitly and will cache the page again.
<p>
Of course, in the previous example, we're saving very little work by output caching. The following example shows the same technique for output caching, but in this example queries a database and displays the results in a grid.
In our final example, we'll modify the application slightly to allow the user to selectively query for authors in various states. This exhibits caching GETs with query strings. For each state in the data set, we have a link that passes the desired state as part of the query string. The application then constructs the appropriate database query and shows authors belonging only to the selected state.
<p>
Note that the first time you click on the link for a given state, it generates a new time stamp at the bottom of the page. Thereafter, whenever request for that state is resubmitted within a minute, you get the original time stamp indicating that the request has been cached.
Applications that want more control over the HTTP headers related to caching can use the functionality provided by the <b>System.Web.HttpCachePolicy</b> class. The following snippet shows code equivalent to the page directives used in the samples we've already seen:
