Caching In Asp.Net

Caching is used to speed up processing of an application.Caching is the process of taking information that is time-instensive to collect and storing it in a location that requires less time to access.

• One could, fairly easily, build their own caching system using Application variables.We can use application-level variables as a cache to store database results. Since application variables are accessible from any page they are quite a logical choice for a caching system.
• 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.
  

ASP.NET supports three types of caching for Web-based applications:

1. Output Caching (Page Level Caching)
   
2. Page Fragment Caching (often called Partial-Page Output Caching)
3. Programmatic or Data Caching

Output Caching

• Output Caching caches the HTML output of dynamic requests to ASP.NET Web pages.
• 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 we have very static HTML pages.
• Output caching can be easily implemented using the @OuputCache page directive.
• The syntax looks like this:
• <%@OutputCache Duration="50" VaryByParam="none" %>
• Duration:This 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.
• VaryByParam:This 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, we may have some content on our page that is fairly static, such as a listing of current inventory, but you may have other information, such as the current stock price of any company, that we 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.
• For this we should not place an OutputCache directive in the ASP.NET Web page that contains the User Control - just put it inside of the User Control.

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.
• 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.
• The syntax looks like this:
• - Cache["ABC"] = str; // C#
- Cache("ABC") = str ' VB.NET
• We Can retrive values by
• - str = Cache["ABC"]; // C#
- str = Cache("ABC") ' VB.NET
• Note that after we retrieve a cache value in the above manner we 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 we attempt to insert something new into the cache, something else will be get!
  
• 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.