Blog Articles

Web Application Caching in ASP.NET

Caching in ASP.NET web applications can happen on multiple levels. As developers, we can greatly increase performance and scalability by caching data or calculations. We can cache at
  1. Data Access layer

    If we are using web services and SOA, then we can use IIS caching to cache our data values. Clearly this may not be appropriate for real-time data, but even a 60 second cache can increase performance without seriously impacting decision making. By decorating our web service like so, we can cache the data for 60 seconds. 

    <WebMethod(CacheDuration:=60)>

    Here's an detailed article about caching in WCF.



  2. Business Object Layer

    Now we have moved a step up the application stack and are dealing with our domain objects. There are two places we can store cache data depending on their expected lifespan.If your page makes heavy use of certain objects, then discards them, you should consider storing the item in the HttpContext.Items collection. Items stored here have a lifespan of 1 request/response cycle. After that they are discarded.



    If our objects are expected to be longer-lived between requests in an application, then a better storage is in the HttpRuntime.Cache.Items collection.





  3. Presentation Layer

    1. Single Control - This technique is known as partial page caching. This allows us to cache a single user control and have the rest of the page be dynamically generated. This is very important for portal and web parts where users may be able to add multiple webparts and make a page relatively "heavy". This technique also allows you to vary the cache by user, querystring, browser and more.


    2. Entire Page - The oldest trick in the book. We add an HTTP Header that tells browsers, and interim cache servers to hold a copy of this page. This keeps the request from ever hitting your server. This approach is best for applications that are updated infrequently, or are updated on a strict schedule. If new content is published on a strict schedule, then you can set the cache to expire just before the new content is published.





There are drawbacks to this approach. When you are debugging, you need to add an additional step to determine if your page is being processed or server from the cache. Like all performance optimizations, this should be done last to keep your system easy and predictable.



Article Tags