Caching Overview

One presentation I give frequently at user groups, internal Microsoft presentations, and conferences is “ASP.NET Performance Best Practices.” I always make the same statement when starting the talk: “We’re going to discuss several areas you should understand to get optimal performance from ASP.NET. The last topic, caching, is the most important.”

Caching is the technique of storing frequently accessed data as close as possible to the resource needing the data. In my opinion, aggressively using the caching features of ASP.NET is the most important design decision you can make when building an ASP.NET Web application that must easily scale and perform well under load. Caching is not unique to ASP.NET. Many other technologies, such as the processor for your computer, use caching to increase performance and scalability. However, the implementation of caching within ASP.NET is unique and was developed specifically for Web applications.

Understanding the caching features of ASP.NET and implementing them correctly allows your applications to perform and scale incredibly well—if you can correctly implement a caching scenario, you can potentially increase performance 3–5 times!

Unfortunately, retrofitting an existing application to support caching is difficult. Caching does have some limitations that affect how the program is architected, and you must understand and account for these nuances early in the architecting phase of your application.

Common Questions about Caching

We’ll begin by answering some common, frequently asked questions about caching in ASP.NET.

When Should I Use Page Output Caching?

Any content created with ASP.NET that does not need to have its code executed upon each request is a candidate for page output caching. For example, pages that display product details, in which the data comes from the database and changes infrequently, are great candidates for output caching. For pages that require further data transformations or that rely heavily on user personalization, partial page caching or the Cache API should be used.

Where Is Cached Data Stored?

Cached data is stored in the memory of the process running the application. It is not stored on disk.

Is Cached Data Shared in a Web Farm?

Unlike session state, data stored within the cache is stored only in the memory of the application in which the data was created. Also, multiple applications on the same server do not share memory and thus cannot share cached data. An application’s cache is private to the application that created it.

Because cached data between applications is never shared, there cannot be cache coherency across the server farm. For example, a page or DataSet cached on server A might be different from a page or DataSet cached on server B. This difference is not a problem, however. Implicitly, you assume that data that can be cached must have some acceptable age limit and that coherency between two or more servers can be loosely controlled through cache dependencies. Additionally, the cache is a feature designed to increase performance, and we know that using an out-of-process session decreases performance by 30–40 percent (mainly due to serialization costs). In version 2 of ASP.NET, you have more control over these dependencies, for example, you can make cache entries dependent upon database tables.

How Long Is an Output Cached Page Stored in Memory?

The duration for which a page can be stored in memory is controlled by several dependencies: time, file, and other cache entries. These dependencies are an inherent feature of the Cache API, which is discussed later in the chapter. As they apply to page output caching, these dependencies are controlled by the developer authoring the page.

What Are the Rules for How a Page Can Be Cached?

Two types of rules can be applied to determine how the page output cache behaves: VaryBy style caching and HTTP cache policy. The first allows output cached pages to vary by data related to the page, for example, query string parameters or HTTP headers. The second, HTTP cache policy, controls how the output cache follows HTTP rules for document caching.

What Happens When the Cache or ASP.NET Needs More Memory?

The page output cache utilizes the ASP.NET Cache API, which implements a least recently used (LRU) algorithm. When ASP.NET has need for more memory, the cache can be asked to evict items to reclaim or free up memory. This eviction process walks through the items stored in the cache and removes items based on two conditions:

• When was the item last used (LRU)

• Which priority was assigned to the item

Internally, the cache sorts the items to be removed first by the least recently used and then by priority. The cache then removes items, removing the lowest priority and least recently used first, and working up based on priority— for example, an item not accessed in a long time but assigned a high priority might never be evicted from the cache. Since the cache manages itself proactively for us, we don’t have to worry about managing it.

Note

When using Microsoft Windows Server 2003 and Microsoft Internet Information Services (IIS) 6, it is recommended to configure the IIS 6 worker process to use 60 percent of the physical memory or to limit the total to 800 MB of physical memory.

How Do I Clear or Flush the Cache?

People frequently ask us how to clear the cache. Unfortunately, there is no Clear method to simply remove everything from the cache. One reason such a method does not exist is because internally ASP.NET is also using the cache to store all sorts of other data, such as configuration. However, it is possible to both individually remove output cached pages (using the output cache API) and items stored in the cache. To remove pages, you must know the name of the page, and to remove items using the Cache API, you must know the name of the key used to retrieve the item.

Now that we’ve gotten the most common questions out of the way, let’s dig into the details of how some of these features work, starting with page output caching.