Caching with ASP.NET
By Scott McFarland
Introduction
In classic ASP, one of the techniques developers commonly relied on to speed up processing was the use of caching. One could, fairly easily, build their own caching system using Application variables, as highlighted in the FAQ, How can I use Application-level variables to cache information? There were also third-party options, like XCache. The main benefits of caching are performance-related: operations like accessing database information can be one of the most expensive operations of an ASP page's life cycle. If the database information is fairly static, this database-information can be cached.
When information is cached, it stays cached either indefinitely, until some relative time, or until some absolute time. Most commonly, information is cached for a relative time frame. That is, our database information may be fairly static, updated just a few times a week. Therefore, we might want to invalidate the cache every other day, meaning every other day the cached content is rebuilt from the database.
While caching in classic ASP was a bit of a chore, it is quite easy in ASP.NET. There are a number of classes in the .NET Framework designed to aid with caching information. In this article, I will explain how .NET supports caching and explain in detail how to properly incorporate each supported method into Web-based applications.
Caching Options in ASP.NET
ASP.NET supports three types of caching for Web-based applications:
- Page Level Caching (called Output Caching)
- Page Fragment Caching (often called Partial-Page Output Caching)
- Programmatic or Data Caching
We'll look at each of these options, including how, and when, to use each option to increase your site's performance!
Output Caching
Page level, or output caching, caches the HTML output of dynamic requests to ASP.NET Web pages. The way ASP.NET implements this (roughly) is through an Output Cache engine. Each time an incoming ASP.NET page request comes in, this engine checks to see if the page being requested has a cached output entry. If it does, this cached HTML is sent as a response; otherwise, the page is dynamically rendered, it's output is stored in the Output Cache engine.
Output Caching is particularly useful when you have very static pages. For example, the articles here on 4GuysFromRolla.com are very static. The only dynamic content is the banners, the dynamic selection being performed on a separate ad server. Hence, the articles on 4Guys would be prime candidates for Output Caching.
Output caching is easy to implement. By simply using the @OuputCache page directive,
ASP.NET Web pages can take advantage of this powerful technique. The syntax looks like this:
<%@OutputCache Duration="60" VaryByParam="none" %>
|
The Duration parameter specifies how long, in seconds, the HTML output of the Web page should be
held in the cache. When the duration expires, the cache becomes invalid and, with the next visit, the
cached content is flushed, the ASP.NET Web page's HTML dynamically generated, and the cache repopulated
with this HTML. The VaryByParam parameter is used to indicate whether any GET (QueryString)
or POST (via a form submit with method="POST")
parameters should be used in varying what gets cached. In other words, multiple versions of a page
can be cached if the output used to generate the page is different for different values passed in
via either a GET or POST.
The VaryByParam is a useful setting that can be used to cache different "views" of a dynamic
page whose content is generated by GET or POST values. For example, you may have an ASP.NET Web page
that reads in a Part number from the QueryString and displays information about a particular widget
whose part number matches the QueryString Part number. Imagine for a moment that Output Caching ignored
the QueryString parameters altogether (which you can do by setting VaryByParam="none").
If the first user visited the page with QueryString /ProductInfo.aspx?PartNo=4, she would see
information out widget #4. The HTML for this page would be cached. The next user now visits and
wished to see information on widget #8, a la /ProductInfo.aspx?PartNo=8. If VaryByParam
is set to VaryByParam="none", the Output Caching engine will assume that the requests to
the two pages are synonymous, and return the cached HTML for widget #4 to the person wishing to see
widget #8! To solve for this problem, you can specify that the Output Caching engine should vary its
caches based on the PartNo parameter by either specifying it explicitly, like
VaryByParam="PartNo", or by saying to vary on all GET/POST parameters, like:
VaryByParam="*".
Partial-Page Output Caching
More often than not, it is impractical to cache entire pages. For example, you may have some content on your page that is fairly static, such as a listing of current inventory, but you may have other information, such as the user's shopping cart, or the current stock price of the company, that you wish to not be cached at all. Since Output Caching caches the HTML of the entire ASP.NET Web page, clearly Output Caching cannot be used for these scenarios: enter Partial-Page Output Caching.
Partial-Page Output Caching, or page fragment caching, allows specific regions of pages to be cached.
ASP.NET provides a way to take advantage of this powerful technique, requiring that the
part(s) of the page you wish to have cached appear in a User Control. One way to specify that the
contents of a User Control should be cached is to supply an OutputCache directive at the
top of the User Control. That's it! The content inside the User Control will now be cached for the
specified period, while the ASP.NET Web page that contains the User Control will continue to serve
dynamic content. (Note that for this you should not place an OutputCache directive in
the ASP.NET Web page that contains the User Control - just inside of the User Control.)
Now that we've tackled Output Caching and Fragment Caching, there is still one more caching technique worth discussing: Data Caching. In Part 2 we'll examine what, exactly, Data Caching is and how you can use it to improve the performance of your ASP.NET Web pages. We'll also examine a really cool, real-world caching demo!
