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" %>

[See a live demo!]

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!

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.

Data Caching
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:

1. Read the myString from the cache: str = Cache("myString")

2. Ensure that str wasn't null/Nothing. If it was, we'd want to get the value of str from
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
End If

Besides using the dictionary-like key/value assignment, as shown in the example above, you
can also use the Insert or 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 it's 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 Cache.Insert method.

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 <Destination> element
contains a <LinkText> and a <NavigateURL> tag to house the appropriate data. Below is a
section of this XML file:

<Destinations>
<Destination>
<LinkText>
Bazquirk
</LinkText>
<NavigateURL>
Bazquik.aspx
</NavigateURL>
</Destination>
<Destination>
<LinkText>Blah</LinkText>
<NavigateURL>Blah.aspx</NavigateURL>
</Destination>
....

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 <LinkText> tags. The HyperLink
control's NavigateUrl property is set to the values contained in the <NavigateURL> 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 ReadXML method.

In the 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!
Conclusion
The .NET caching services will prove to be one of the most powerful ways to squeeze
performance out of new Web-based applications. Whether using Output Caching, Fragment
Caching, or the Cache object directly, your web applications will see dramatic improvements in
throughput and scalability through the technique of caching expensive dynamic data
computations.

Happy Programming!

<%@OutputCache Duration="durationInSeconds" VaryByParam="varyBy" %>

File Dependent Data Caching

This demo highlights file dependent data caching. The content in the DataList below is
populated from an XML file. The contents of the XML file, however, are cached with a
file dependency on the actual on-disk XML file, meaning that the XML cache will be
invalidated when the XML file on-disk is edited.
Links
Bazquirk
Blah
Foobar
Ipsum
Dolor

Source Code

<%@Import Namespace="System.Data"%>
<script runat="server" language="C#">
void Page_Load(Object sender, EventArgs e)
{
BindDestinations();
}

private void BindDestinations()

{
DataView dv = (DataView) Cache["Destinations"];

if(dv == null)
{
DataSet ds = new DataSet();
string path = Request.MapPath(Request.ApplicationPath);
ds.ReadXml (path +
"\\demos\\Destinations.xml",XmlReadMode.InferSchema);
dv = ds.Tables[0].DefaultView;
Cache.Insert("Destinations", dv, new CacheDependency (path +
"\\demos\\Destinations.xml"));
 lblTime.Text = "Data was loaded from the cache at " +
DateTime.Now.ToString() + ".";
}

DataList1.DataSource = dv;
DataBind();
}
</script>

<asp:DataList DataKeyField="LinkText" id="DataList1" runat="server"

Width="100px">
<HeaderStyle BackColor="#aaaadd" Font-Bold="True" Font-
Name="Arial" Font-Size="12"></HeaderStyle>
<AlternatingItemStyle BackColor="#FFFFCC" Font-Name="Arial"
Font-Size="8"></AlternatingItemStyle>
<ItemStyle BackColor="#FFFFFF" Font-Name="Arial" Font-
Size="8"></ItemStyle>
<HeaderTemplate>
Links
</HeaderTemplate>
<ItemTemplate>
<asp:HyperLink id=HyperLink1 Target="_top" Text='<%#
DataBinder.Eval(Container.DataItem, "LinkText") %>' NavigateUrl='<%#
DataBinder.Eval(Container.DataItem, "NavigateURL") %>'
runat="server" >
</asp:HyperLink>
</ItemTemplate>
<SelectedItemTemplate>
<asp:HyperLink id=HyperLink2 Text='<%#
DataBinder.Eval(Container.DataItem, "LinkText") %>' NavigateUrl='<%#
DataBinder.Eval(Container.DataItem, "NavigateURL") %>'
runat="server" >
</asp:HyperLink>
</SelectedItemTemplate>
</asp:DataList>
<br>
<asp:Label id="lblTime" runat="server" Width="450px" Font-
Bold="True" Font-Names="Tahoma"></asp:Label>

http://aspnet.4guysfromrolla.com/demos/FileDeptDataCaching.aspx

One of the coolest features of the Cache class is the ability to exert fine-grained control over its behavior with
various types of dependencies. The file-based dependency is one of the most useful - a file dependency is added
by using Cache.Insert and supplying a CacheDependency object referencing the file we want to have monitored:

Cache.Insert("MyData", Source, new CacheDependency(Server.MapPath("authors.xml")));

But what if we want to invalidate the Cache based on changes to our Database - a scenario that is highly likely in
many application scenarios? There is no direct built - in Cache support for monitoring Database tables for
changes. It turns out that with the use of a relatively infrequently used SQL Server system sproc,
sp_makewebtask, it is possible to accomplish this objective. This sproc was designed to create web pages from
queries, but with only the slightest modification -- employing it in a trigger -- we can gain a reasonably efficient way
to "touch" a specified file on update, insert or delete from a specific table. This causes the file monitoring process in
the CacheDependency instance to detect a change, and invalidate the cache. In fact, since CacheDependency
works with UNC file protocol, we can have this work even throughout a web farm, where each machine's copy of
the app monitors the same file on a single machine in the farm through a UNC path to the file.

Without further discussion, let's put together a sample Web Application to illustrate how this can be done in it's
simplest form. First, we'll use the trusty stock Northwind sample database in SQL Server where we can show a
simple DataGrid of the Employees table. (Poor Nancy - her record has been changed so many times <grin/>). The
fitrst thing we need to do is set up our trigger:

CREATE TRIGGER WriteCacheDepFile ON [dbo].[Employees]

FOR INSERT, UPDATE, DELETE
AS
EXEC sp_makewebtask '\\peter\C$\Cache\mycache.txt', 'SELECT top 1 FirstName FROM employees'

What we did above is simply tell SQL Server that if anything at all happens to the Employees table, write a file
"mycache.txt" based on a simple query. The query can really be anything at all; as long as it's valid T-SQL, SQL
Server will happily update the file.

Next, we need to actually create the directory, and make it a share. You may also need to update permissions so
the file can be written. Note that I've used the Administrative share "C$". You may also need to create an initial
blank file, "mycache.txt".

Now we are all ready to create our app. First, let's put the dependency file into our web.config so it's easy to
change without redeployment:

In web.config, near the bottom, add an

appSettings section like so:
</system.web>

<appSettings>
<!-- modify line below to suit actual location of your cache folder -->
<add key="dependencyFile" value="\\peter\Cache\mycache.txt" />
</appSettings>

</configuration>

Now, let's set up our Cache mechanism in our Global

class so we won't need any page specific code:
Public Class Global
Inherits System.Web.HttpApplication
Dim _cache As System.Web.Caching.Cache = Nothing
Public Shared blnRefreshed As Boolean = False

Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)

_cache = Context.Cache
RefreshCache(Nothing, Nothing, Nothing)
End Sub

Shared Sub RefreshCache(ByVal key As String, ByVal item As Object, ByVal reason As
System.Web.Caching.CacheItemRemovedReason)

Dim adapter As SqlDataAdapter = New SqlDataAdapter("SELECT EmployeeID, lastname, firstname FROM

Employees", "server=localhost;database=Northwind;uid=sa;pwd=")

Dim ds As New DataSet()

adapter.Fill(ds, "Employees")
Dim onRemove As CacheItemRemovedCallback = New CacheItemRemovedCallback(AddressOf RefreshCache)
Dim depFile As String = System.Configuration.ConfigurationSettings.AppSettings("dependencyFile").ToString()

System.Web.HttpContext.Current.Cache.Insert("Employees", ds, New CacheDependency(depFile), _

Cache.NoAbsoluteExpiration, Cache.NoSlidingExpiration, _
CacheItemPriority.High, onRemove)
blnRefreshed = True
End Sub

Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)

If HttpContext.Current.Cache("Employees") Is Nothing Then
RefreshCache(Nothing, Nothing, 0)

End If

As can be seen above, we' ve defined _cache as an object of type Cache. In our Application_Start method we set
it to the current instance of the Cache, and call the RefreshCache method to fill it. RefreshCache is actually as
Shared (static) delegate callback. What it does is simply retrieve a DataSet of the Employees table. It then sets up
the required CacheItemRemovedCallback pointing to RefreshCache so that we can set up the dependency based
on our dependency file. We set up our callback "onremove" to point to this method.

Finally, we insert the DataSet into the Cache along with our onRemove callback delegate. And in Session_Start,
just to be "sure" I've added another optional checking call to RefreshCache to "bake it".

At this point, our app is all set up to use in any page that needs access to the cached DataSet. In WebForm1.aspx,
I've illustrated how this can be used:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

' Make sure Cache item ain't empty, if it is, fill it up
If Cache("Employees") Is Nothing Then
Global.RefreshCache(Nothing, Nothing, 0)
cacheStatus.Text = "Cache Refreshed at " & DateTime.Now.ToLongTimeString
Else
cacheStatus.Text = " DataSet from Cache "
End If
Dim ds As DataSet
ds = CType(Cache("Employees"), DataSet)
DataGrid1.DataSource = ds.Tables(0)
DataGrid1.DataBind()
End Sub
And that's it! If you request this page, it will show that the DataSet is successfully
retrieved from Cache every time. However, if you leave your browser open and fire up
Query Analyzer pointed to your Norhtwind database, and execute some query such as
'Update Employees set Lastname = 'Davovlieu' where EmployeeID =1' which changes
something in the table, and then re-request the page, then the next time it is loaded, you'll
see that the cache has been invalidated and refreshed.

The Solution download below is Visual Studio.NET 2003. If you don't have 2003 yet, just
start a new Web Application and bring in the web.config, global.asax and Webform1.aspx
files and all their associated codebehind class files.