Caching

.Caching with 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 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, its output is stored in the Output Cache engine. Output Caching is particularly useful when you have very static pages. It 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="*". The full spec for the @OutputCache lines is: <%@ OutputCache Duration="#ofseconds" Location="Any ¦ Client ¦ Downstream ¦ Server ¦ None" VaryByControl="controlname" VaryByCustom="browser ¦ customstring" VaryByHeader="headers" VaryByParam="parametername" %> Duration is a count in seconds to cache. Location allows the caching to occur on the server, on the client, on a proxy server in between. The default is Any. If you always want server caching (which seems to me to be the most useful choice), change the line to read: <%@ OutputCache Duration="3600" Location="Server" VaryByParam="none"%> VaryByControl is only used by user controls, not on standard web pages.

VaryByCustom="browser" keeps a different copy of the output for each browser name and major version information. So if you have cloaking by browser version going on (which is easy to implement in .NET), then each separate page will get delivered. VaryByCustom="customstring" Allows you to specify a string that will be passed to your code. To make this useful, you must then override the GetVaryByCustomString method in the Global.asax file. For example, place this line in your ASPX file: <%@ OutputCache Duration="3600" Location="Server" VaryByCustom="Referer" VaryByParam="none"%> Then in your Global.asax file add the following code: public override String GetVaryByCustomString(System.Web.HttpContext hcContext, String strCustom) { switch (strCustom) { case "Referer": Uri uriReferrer = hcContext.Request.UrlReferrer; String strRet; if (uriReferrer != null) strRet = uriReferrer.Host; else strRet = null; return strRet; default: return base.GetVaryByCustomString(hcContext, strCustom); } } VaryByHeader allows you to cache based off of some field in the HTTP header sent by the client. The classic example is based off the Accept-Language header line. VaryByParam allows you to cache different versions based off of querystring or post field parameters. So http://www.domain.com/foo.aspx?bar=baz would be cached separately from http://www.domain.com/foo.aspx?bar=bletch 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.) Data Caching In simple terms data caching is storing data in memory for quick access. Typically information that is costly to obtain (in terms of performance) is stored in the cache. One of the more common items stored in a cache in a Web application environment is commonly displayed database values; by caching such information, rather than relying on repeated database calls, the demand on the Web server and database server's system resources are decreased and the Web application's

scalability increased. As Microsoft eloquently puts it, "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." Using Data Caching The .NET data caching API is comprised of the two classes in the System.Web.Caching namespace. The first class, Cache, is the class we'll be using to add and remove items from the data cache. The second class, CacheDependency, is used when assigning a cache dependency to an item in the data cache. To add an item to the cache you can simply do: Cache["key"] = value; // In C# The above code adds the item value to the data cache with the key “key”. The key is used to reference the item at some later point. That is, in another ASP.NET Web page we can extract the value inserted above by using: value = Cache("key") - or value = Cache.Get("key") To explicitly remove an item from the data cache you can use the Remove method, specifying the key of the cache item you want removed: Cache.Remove("key") Inserting an Item into the Cache Inserting an item into the data cache is as simple as saying Cache["key"] = value. Items can also be inserted into the cache using the Insert method, which allows for more powerful semantics on how the item in the cache should be handled. Specifically, the Insert method has four overloaded forms, as shown below: 1. Insert(key as String, value as Object) - Inserts the object value into the cache, giving the item the key name key. This is semantically equivalent to using Cache("key") = value. 2. Insert(key as String, value as Object, dependencies as CacheDependency) - Inserts the object value into the cache with key name key and dependencies specified by the dependencies parameter. We'll discuss cache dependencies shortly. 3. Insert(key as String, value as Object, dependencies as CacheDependency, absoluteExpiration as DateTime, slidingExpiration as TimeSpan) - Inserts the object value into the cache with key name key, dependencies dependencies, and (time-based) expiration policies. Expiration policies, as we'll discuss soon, specify when the item should be evicted from the cache. 4. Insert(key as String, value as Object, dependencies as CacheDependency, absoluteExpiration as DateTime, slidingExpiration as TimeSpan, priority as CacheItemPriority, onRemoveCallBack as CacheItemRemovedCallback) - Inserts the object value into the cache with key name key, dependencies dependencies, (time-based) expiration policies, a cache priority, and a callback delegate. The priority specifies how important it is for the cache item to remain in the cache. That is, items with a lower priority will be evicted from the cache before items with a higher priority. The callback delegate provides a means for you to create your own function that is automatically called when the item is evicted from the cache. The above list of the various forms of the Insert method may look quite daunting. Most often you'll likely use either form 1, 2, or 3. Let's take a moment to discuss the CacheDependency and absolute and sliding time parameters. Recall that information stored in the data cache is being stored on the Web server's memory. In a perfect world, when an item is added to the cache using Insert(key, value) or Cache("key") = value, the item will remain in the cache forever. Unfortunately this is not plausible in the real

world. If the computer the Web server runs on is rebooted, or shuts off, for example, the cache will be lost. Even if the Web server machine is running, you may lose items from the cache. To see why, imagine that your Web server has allocated one MB of memory for storing items in the data cache. Now, imaging that you've added a number of items to the data cache such that you've used exactly 1 MB of memory. Great. Now, what happens when you add another item to the data cache? In order for the new item to "fit," the data cache needs to make room for it by removing an existing item. The existing item that is chosen to be removed is said to be evicted. There may be times when you don't want an item to exist in the cache indefinitely. For example, say that you were displaying an XML file in an ASP.NET DataGrid. Rather than load the XML file into a DataSet and bind the DataSet to the DataGrid each page view, you may opt to cache the DataSet in the data cache. This option would work great until the XML file was altered; at that point, if you were still displaying the cached DataSet the user would be seeing stale information. To overcome this problem, you can add the DataSet to the data cache, but specify that the XML file it represents is a cache dependency. By setting this file as a cache dependency, when the file changes the DataSet will be automatically evicted from the cache. That means the next time the DataSet is attempted to be read from the cache, it will not be found (since it has been evicted) and will be recreated by repopulating the DataSet from the XML file. This is desired since the XML file has changed since the DataSet was last cached. In order to insert an item with a cache dependency, you can do: Cache.Insert("key", myDataSet, New CacheDependency(Server.MapPath("data.xml"))) If you wish to have the cache item evicted from the cache in an absolute time, say, five minutes from when it was inserted into the cache, you can use the third form of the Insert method, whose fourth parameter expects a DateTime value specifying the absolute time. The following code illustrates how to add an item to the cache that will expire five minutes from when it was added and has no cache dependencies: Cache.Insert("key", value, Nothing, DateTime.Now.AddMinutes(5), TimeSpan.Zero) In C# you would use null instead of Nothing to signify that you do not want a cache dependency. Note that since we do not want to specify sliding time expiration, we set the last parameter to TimeSpan.Zero. Whereas an absolute time specifies that the item should be evicted from the cache at a specific time, the sliding time eviction parameter specifies that the cache item should be evicted if it is not referenced in a certain timespan. That is, if we set the timespan parameter to, say, TimeSpan.FromSeconds(30), the cache item will be evicted if it is not referenced within 30 seconds. If it is referenced within 30 seconds, it will be evicted if it's not referenced in another 30 seconds from when it was last referenced, and so on. An example of this would be: Cache.Insert("key", value, Nothing, DateTime.Now, TimeSpan.FromSeconds(30), TimeSpan.Zero) Note that when using the sliding time expiration parameter, the absolute expiration parameter value does not matter. That is, it is automatically set to DateTime.Now and has the sliding time added to it to determine the absolute time the cache item should expire. Of course, if the item is referenced within that time period, the calculation is redone and the absolute expiration time is reset. Before we move on to some examples, let's take a quick look at the CacheItemRemovedCallback delegate. Recall that you can set this in the fourth overloaded form of the Insert method. The CacheItemRemovedCallback specifies a function that is called when the item has been evicted from the cache. To use the CacheItemRemovedCallback you need to first create a function that has the definition: Sub CallbackFunction(String, Object, CacheItemRemovedReason) The CacheItemRemovedReason is an enumeration that explains why the item was removed from the cache. Its entries include: 1. DependencyChanged - the item was removed because its cache dependency was changed.

2. Expired - the item was removed because it expired (either by absolute or sliding time expiration). 3. Removed - the item was explicitly removed via the Remove method. 4. Underused - the item was evicted by the cache because the system needed to free up memory. To add a CacheItemRemovedCallback function to an added cache item you will need to create the appropriate function and a delegate variable that is wired up to the function, as shown below: 'You would use onCacheRemove as the input parameter for the 'CacheItemRemovedCallback parameter in the fourth form of the Insert method Dim onCacheRemove As CacheItemRemovedCallback OnCacheRemove = New CacheItemRemoved(AddressOf Me.CheckCallback) ' Now, create the function Sub CheckCallback (str As String, obj As Object, reason As CacheItemRemovedReason) Response.Write ("Cache was removed because : " & reason) End Sub