Increase Web site performance with ASP.NET caching

by Tony Patton | Jun 27, 2006 3:29:00 PM

Tags: .NET, Performance management, Channel management, Middleware, Microsoft development tools, Tony Patton, Page Output, Microsoft ASP.NET, Web, performance, .NET Newsletter

Takeaway: Caching frequently accessed Web page data is one way to positively impact a Web application's performance. Find out how ASP.NET makes it easy to cache data.

While functionality is the number one goal of Web development, performance seems to be a close second. After all, a site that isn't used serves no purpose. Caching frequently accessed Web page data is one way to positively impact a Web application's performance. ASP.NET includes caching support that is easily incorporated in your application to boost application performance.

ASP.NET 1.x provides three ways to incorporate caching in a Web application:

• Page Output caching: allows you to cache the dynamically generated page content.
• Page Fragment caching: caches portions of a Web page.
• Page Data caching: programmatically caches data/objects within a Web page.

In this article, I will focus my attention on Page Output caching.

Page Output caching

Output caching is applicable when the contents of an entire page are relatively static so it may be cached. Caching frequently accessed pages can result in substantial throughput gains. The way it works is initial page requests are generated dynamically with all subsequent requests served from the cache. The result is an enormous performance gain with heavily used applications.

The main aspect of caching a page is the expiration date. It determines how long content will be retained in the cache before it is reloaded from the source. It is accessible via code or with the page-level OutputCache directive. It includes the Duration parameter for specifying how long an item will be cached (in seconds). Along with Duration, the OutputCache directive contains the following attributes:

• Location: The location of the cache. Valid values include Any, Client, Downstream, None, Server, and ServerAndClient. The default value is Any.
• CacheProfile: The name of the cache settings to associate with the page. It is an optional element with no default value.
• NoStore: A Boolean value signaling whether to prevent secondary storage of sensitive data.
• Shared: A Boolean value that determines whether user control output can be shared with multiple pages.
• VaryByCustom: Any text that represents custom output caching requirements.
• VaryByHeader: A semicolon-separated list of HTTP headers used to vary the output cache.
• VaryByParam: A semicolon-separated list of strings used to vary the output cache.

The key elements used most frequently are Duration and VaryByParam, which allows you to create different page level caches based on parameters.

These parameters correspond to querystring values sent with HTTP GET requests or form parameters sent along with HTTP POST requests. When this attribute is set to multiple parameters, the output cache contains a different version of the requested document for each combination of specified parameters. Possible values include none, an asterisk (*), and any valid query string or POST parameter name.

Listing A contains a basic approach to page level caching with a C# page that loads employee data from the venerable SQL Server Northwind database. The data is relatively static, so it is cached for five minutes. Listing B contains the equivalent VB.NET code.

It is rare for data to be presented without parameters specified. The page in Listing C uses the VaryByParams parameter to cache employee data displayed for specific users (specified via employeeidQueryString value). Listing D contains the equivalent VB.NET code.

The result is the caching of page data per employeeidquerystring parameter. It could result in a large amount of data in memory given a large number of employee requests, but it is only cached for a minute. If your application has multiple parameters, you should separate them with commas in the VaryByParam parameter.

The two approaches covered in the previous examples are the most common application of page level caching, but (as the parameter list shows) there are numerous options available depending upon your application.

Proceed with caution

While caching is a great feature to boost an application's performance via page response times, you should only use it when appropriate. Utilizing caching features in an application comes with a price—Web server resources. Cached items are stored in the Web server's memory. This memory pool is finite, so it may be totally consumed if you overuse caching. Although, if system memory is totally consumed, the contents of the cache will be cleared (so the system can run). With that said, use ASP.NET caching wisely.

ASP.NET 2.0

The most recent iteration of ASP.NET builds upon the caching features provided in version 1.x. ASP.NET 2.0 extends caching by providing database triggered cache invalidation capabilities. It allows you to easily ensure cache items are kept up-to-date with the changes in the database. It is available with both declarative and programmatic output caching, as well as via the Cache API and the SqlCacheDependency object. I will cover this in much more detail in a future article.

Perception is everything

Nothing defines Web application acceptance by users more than page response times. Instant or near-instant load times are expected. Web developers work hard to deliver applications with acceptable response times. ASP.NET provides help with various page and data options that can be used to decrease the number of calls for data and thus decreasing load time.

Miss a column?

Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

Print/View all Posts Comments on this article

listing B erroraikimark@...  | 06/28/06