16.0 Introduction

ASP.NET gives you the ability to cache the output of pages or portions of pages in memory to improve performance. The main reason to cache is to reduce the latency and increase the scalability of an application while reducing the server resources required to deliver its page content. Latency is a measure of the time it takes for an application to respond to a user request. Scalability is the ability of an application to handle increased numbers of users. If a page is cached on the server, the rendered HTML stored in memory is served instead of a freshly generated page from the server. Because it takes less time for the client to get the page and display it, your web site will seem more responsive.

If pages are completely static, deciding to cache them is a no-brainer. But the decision gets trickier if pages must vary their content in response to one of the following:

• Query string parameters

• Client browser type (e.g., Internet Explorer, Netscape, and so on)

• Custom parameters

• Database content

Sometimes it makes sense to cache such pages, and sometimes not, as you will soon see.

ASP.NET provides the ability to cache data items to enhance performance. But what if the data items occasionally change? Does it still make sense to cache them? The answer is a definite yes, provided you know how to refresh the cache when the data changes.

ASP.NET 2.0 now allows for many new caching possibilities, including database-triggered cache invalidation and the ability to create custom cache dependencies. The recipes in this chapter cover how to use these new capabilities in the context of some of the more useful caching scenarios. Nevertheless, ASP.NET 2.0 caching is a large topic that will undoubtedly spawn many articles and to cover it exhaustively would be beyond the scope of this book.