Caching is a technique widely used in computing to increase performance by keeping frequently accessed or expensive data in memory. In the context of a Web application, caching is used to retain pages or data across HTTP requests and reuse them without the expense of recreating them.
ASP.NET has three kinds of caching that can be used by Web applications:
Ã‚Â· Output caching, which caches the dynamic response generated by a request.
Ã‚Â· Fragment caching, which caches portions of a response generated by a request.
Ã‚Â· Data caching, which caches arbitrary objects programmatically. To support this, ASP.NET provides a full-featured cache engine that allows programmers to easily retain data across requests.
Output caching is useful when the contents of an entire page can be cached. On a heavily accessed site, caching frequently accessed pages for even a minute at a time can result in substantial throughput gains. While a page is cached by the output cache, subsequent requests for that page are served from the output page without executing the code that created it.
Sometimes it is not practical to cache an entire page - perhaps portions of the page must be created or customized for each request. In this case, it is often worthwhile to identify objects or data that are expensive to construct and are eligible for caching. Once these items are identified, they can be created once and then cached for some period of time. Additionally, fragment caching can be used to cache regions of a page's output.
Choosing the time to cache an item can be an interesting decision. For some items, the data might be refreshed at regular intervals or the data is valid for a certain amount of time. In that case, the cache items can be given an expiration policy that causes them to be removed from the cache when they have expired. Code that accesses the cache item simply checks for the absence of the item and recreates it, if necessary.
The ASP.NET cache supports file and cache key dependencies, allowing developers to make a cache item dependent on an external file or another cache item. This technique can be used to invalidate items when their underlying data source changes.
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!
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" %>
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.
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
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:
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!
In Part 1 we looked at how to use Output Caching and Fragement Caching of an ASP.NET Web page. These two techniques cached either the full HTML output of an ASP.NET Web page, or a portion of the HTML output of an ASP.NET Web page (by caching the HTML output of a User Control). In this part, we'll examine Data Caching, which is an in-memory cache used for caching objects.
Sometimes, more control over what gets cached is desired. ASP.NET provides this power and flexibility by providing a cache engine. Programmatic or data caching takes advantage of the .NET Runtime cache engine to store any data or object between responses. That is, you can store objects into a cache, similar to the storing of objects in Application scope in classic ASP. (As with classic ASP, do not store open database connections in the cache!)
Realize that this data cache is kept in memory and "lives" as long as the host application does. In other words, when the ASP.NET application using data caching is restarted, the cache is destroyed and recreated. Data Caching is almost as easy to use as Output Caching or Fragment caching: you simply interact with it as you would any simple dictionary object. To store a value in the cache, use syntax like this:
Cache["foo"] = bar; // C#
Cache("foo") = bar ' VB.NET
To retrieve a value, simply reverse the syntax like this:
bar = Cache["foo"]; // C#
bar = Cache("foo") ' VB.NET
Note that after you retrieve a cache value in the above manner you should first verify that the cache value is not null prior to doing something with the data. Since Data Caching uses an in-memory cache, there are times when cache elements may need to be evicted. That is, if there is not enough memory and you attempt to insert something new into the cache, something else has gotta go! The Data Cache engine does all of this scavenging for your behind the scenes, of course. However, don't forget that you should always check to ensure that the cache value is there before using it. This is fairly simply to do - just check to ensure that the value isn't null/Nothing. If it is, then you need to dynamically retrieve the object and restore it into the cache.
For example, if we were storing a string
myString in the cache whose value was set from some method named
SetStringToSomething(), and we wanted to read the value of
myString from the cache, we'd want to:
- Read the
myString from the cache:
str = Cache("myString")
- Ensure that
str wasn't null/Nothing. If it was, we'd want to get the value of
SetStringToSomething(), and then put it in the cache, like so:
'Try to read the cache entry MyString into str
str = Cache("myString")
'Check if str is Nothing
If str is Nothing then
'If it is, populate str from SetStringToSomething()
str = SetStringToSomething()
'Now insert str into the cache entry myString
Cache("myString") = str
Besides using the dictionary-like key/value assignment, as shown in the example above, you can also use the
Add method to add items to the cache. Both of these methods are overloaded to accommodate a variety of situations. The
Add and the
Insert methods operate exactly the same except the
Add method returns a reference to the object being inserted to the cache. Because of the similarity of the two methods, I will concentrate on the
Insert method. Note that the
Insert method allows you to simply add items to the cache using a key and value notation as well. For example to simply add an instance of the object
bar to the cache named
foo, use syntax like this:
Cache.Insert("foo", bar); // C#
Cache.Insert("foo", bar) ' VB.NET
(Note that this is synonymous to using the
Cache("foo") = bar syntax we looked at earlier.)
Note that with inserting items into the Data Cache using the
Cache(key) = value method or the
Cache.Insert(key, value) we have no control over when (if ever) the items are evicted from the cache. However, there are times when we'd like to have control over when items leave the cache. For example, perhaps we want to have an inserted item in the cache to only live for n seconds, as with Output Caching. Or perhaps we'd like to have it exit the cache n seconds after its last accessed. With Data Caching, you can optionally specify when the cache should have a member evicted.
Additionally, you can have an item evicted from the cache when a file changes. Such an eviction dependency is called a file dependency, and has many real-world applications, especially when working with XML files. For example, if you want to pull data out of an XML file, but you don't want to constantly go to disk to read the data, you can tell the ASP.NET caching engine to expire the cached XML file whenever the XML file on disk is changed. To do this, use the following syntax:
Cache.Insert("foo", bar, new CacheDependancy(Server.MapPath("BarData.xml")))
By using this syntax, the cache engine takes care of removing the object
bar from the cache when
BarData.xml file is changed. Very cool! There are also means to have the inserted cache value expire based on an interval, or at an absolute time, as discussed before. For more information on these methods, consult the documentation for the
A Cached XML File Example
Hopefully by now you'll agree that one of the most interesting and useful uses of the
Cache.Insert method involves using the version of the method that takes advantage of the
CacheDependancy parameter. By using this parameter, developers can create web pages that contain "semi-static" data. In other words, the rendering of the pages is based on configuration-like data which can be stored in an XML file (or anywhere really, I just like to use XML for this type of data). But I digress. The point is, why go back to disk or, worse yet, a SQL Server just to retrieve data that only changes periodically when I can have it done automatically.
To illustrate this point, I've created a simple example. In this example, an XML file is used to house data that is used to create a simple navigation control. Each
element contains a
tag to house the appropriate data. Below is a section of this XML file:
In a User Control a DataList control is used to bind the XML data using a HyperLink control. The Text property is set to the values contained in the
tags. The HyperLink control's
NavigateUrl property is set to the values contained in the
tags. A Label control is used in the code behind class to output the time the cache is updated. (All of the code, and the output, can be seen at this live demo!)
A simple method,
BindDestinations, does the work of binding the XML data to the DataList control. This method is called everytime the
Page_Load event is fired. A DataSet object is created and then filled with the XML data by using the DataSet's
BindDestinations method, an attempt is made to pull the data out of the Cache object. If nothing is found, as is the case when the XML file is changed, the data is re-read from the XML file and re-inserted into the Cache object. The time this occurs is also displayed via the
lblTime Label control. Finally, the data is bound to the DataList control and displayed. In this manner, the data of the page is cached until it needs to be refreshed (i.e., the XML file data is changed). Neat!