ASP.NET Cache

Used while sharing data across users based on dependencies and expiration policies.
Cache values can be accessed using
Name space     -System.Web
Class object of - HttpContext or Page
Property           - Cache

It has the greatest potential impact on an application's performance

Tip:
Cache Early; Cache Often

Implement caching at every layer of your application. Add caching support to the data layer, the business logic layer, and the UI or output layer. Memory is cheap—by implementing caching in an intelligent fashion throughout the application, you can achieve great performance gains.

Types of dependencies
Type	Brief Description
File dependency	Allows you to invalidate a specific cache item when a disk based file or files change.
Time-based expiration	Allows you to invalidate a specific cache item depending on predefined time.
Key dependency	Allows you to invalidate a specific cache item depending when another cached item changes.

Table 1.

 

Cache Callback

As cache object is created according to some dependency (ref table 1) and expires or removed while there is change in corresponding dependency and ASP.NET execute/capable to fire a cache callback method corresponding to this removal of object to add the items back in cache.

ASP.NET has a full-featured cache engine that can be used by applications to store arbitrary objects in memory. This mechanism is implemented via the Cache class, an instance of which exists for each application configured on a web server. The application cache provides a simple dictionary interface using key/value pairs that enables you to store and retrieve objects from the cache.

Forms of caching
Type	Advantages
page level output caching,	provides additional flexibility and can be used to take advantage of caching throughout every layer of an application.
user control level output caching (or fragment caching)	advantage of being incredibly simple to implement
Cache API

Page Level Output Caching

e.g.

<%@OutputCache Duration="60" VaryByParam="*"%>

The various types of parameters that can be used in this form of caching is discussed as below:

Param name	Description
Duration	Required. Time, in seconds, the page should be cached. Must be a positive integer.
Location	Specifies where the output should be cached. If specified, must be one of: Any, Client, Downstream, None, Server or ServerAndClient.
VaryByParam	Required. The names of the variables in the Request, which should result in, separate cache entries. "none" can be used to specify no variation. "*" can be used to create new cache entries for every different set of variables. Separate variables with ";".
VaryByHeader	Varies cache entries based on variations in a specified header.
VaryByCustom	Allows custom variations to be specified in the global.asax (for example, "Browser").

Most situations can be handled with a combination of the required Duration and VaryByParam options. VaryByHeader and VaryByCustom are primarily used to allow customization of the page's look or content based on the client that is accessing them.

In order to enable separate cache entries for each browser, VaryByCustom can be set to a value of "browser". This functionality is built into the caching module, and will insert separate cached versions of the page for each browser name and major version.

<%@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser"  %>

Fragment Caching, User Control Output Caching

Fragment caching uses the same syntax as page level output caching, but applied to a user control (.ascx file) instead of to a web form (.aspx file).

In addition to parameters used for page level output caching an additional an OutputCache attribute named "VaryByControl" is included in fragment caching, which will vary the caching of the user control depending on the value of a member of that control(typically a control on the page, such as a DropDownList).

If VaryByControl is specified, VaryByParam may be omitted.

By default each user control on each page is cached separately. However, if a user control does not vary between pages in an application and is named the same across all such pages, the Shared="true" parameter can be applied to it, which will cause the cached version(s) of the user control to be used by all pages referencing that control.

e.g. 1. Separate cache for variation of query string and page containing control.

<%@ OutputCache Duration="60" VaryByParam="*" %>

Creates a separate cache for control for 60 sec and created

for every variation of query string and page containing control.

e.g. 2. Separate cache creation with variation of selected value in

CountryDropDownList control.

<%@ OutputCache Duration="60" VaryByParam="none" 
VaryByControl="CountryDropDownList" %>

User control cached for 60 sec and cached for each changed
value of control "CountryDropDownList".

e.g. 3.  Separate cache creation with each browser name and
variation of major version

<%@ OutputCache Duration="60" VaryByParam="none" 

VaryByCustom="browser" Shared="true %>

Created cache expires after 60 sec which gets created

for every change in browser name and major version.

The cache entries for each browser would then be 

shared by all pages referencing this user control (as long

as all pages refer to the control with the same ID).

 

Caching API, Using the Cache Object

Using the Cache object, you can store any serializeable data object, and control how that cache entry expires based on a combination of one or more dependencies.

Storing Data in the Cache

1. The simplest way to store data in the Cache is simply to assign it, using a key, just like a HashTable or Dictionary object:

Cache["key"] = "value";

This will store the item in the cache without any dependencies,
so it will not expire unless the cache engine removes it in order to
make room for additional cached data.

2. To include specific cache dependencies, the Add() or Insert()
method is used. Each of these has several overloads.

Add() --> Returns a reference to the cached object and do nothing if
item with same key already exists
Insert() --> Has no return value and overwrite the item if item with
same key name already exists.


3. Other Options:

a. Specifying the priority of the item (from low to high to NotRemovable):  defined in the System.Web.Caching.CacheItemPriority enumeration

b. CacheItemRemovedCallback option allows some interesting possibilities.