Managing Application and Request State

Application and request state refer to any data that is accessible for the lifetime of either the application or the request. Static variables, the Cache, and Application can all be used to store application state. Per-request state can be stored using HttpContext.Items.

• 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.

• 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. As they apply to page output caching, these dependencies are controlled by the developer authoring the page.

• The ASP.NET Cache 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 memory.

• 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.

• Use the page directives when possible. There is less risk of introducing bugs in your application because the OutputCache directive is declarative.

• An Etag, or entity tag, specifies an HTTP header sent with the served document to uniquely identify a specific version of the page. Cache servers can query the originating cache server to determine whether a cached document is still valid by comparing the cached documents entity tag to the entity tag returned from the origin server.

• If VaryByParam is not used, why is it required and why is its value set to none? The decision was made to force the developer to add VaryByParam with a value of none to clearly indicate that the page was not varying by any parameters. Requests with parameters sent to an output cached page using VaryByParam with none will not be resolved by the output cache and are treated as misses.

• A single parameter can be specified, for example, VaryByParam=“tabindex”. Multiple parameters to be varied by must be semicolon-separated, for example, VaryByParam=“tabindex;tabId”.

• Varying the output cache by various parameters is very useful. However, here is a good rule of thumb to keep in mind: the more specific the request, the less likely it is that the request can be satisfied from the cache. For example, if the page’s output is highly user-specific, such as an e-commerce check-out page, the output cached page could be utilized again only by that same user in the same condition (in contrast to output caching the page used to display product information). When items are stored in the cache and cannot be utilized again, the cache is a wasted resource.

• Do not use VaryByParam with * unless absolutely necessary. Any arbitrary data passed in the query string or POST body will affect how many versions of the output cached page are created, thus potentially filling memory with many pages that can’t be used again.

• If you have the .NET Framework installed and are using Internet Explorer, a .NET CLR [version #] string will be added as part of the User-Agent header. This can be useful for users who are downloading .NET applications because you can determine whether they also need to download the .NET Framework.

• Page output cache directives are additive, and you should plan to use more than just the required VaryByParam for pages containing server controls that behave differently for different browser types. Otherwise inconsistencies will occur, as Internet Explorer DHTML could potentially be sent to a Netscape 4 browser (if the output cache is not being varied by browser type).

• Don’t use the Location attribute unless you completely understand how it works. In the majority of cases, its use is unnecessary.

• Do not use the page OutputCache directive on a page that also uses the output Cache APIs. If used together, the more restrictive setting is applied. Thus, if the page OutputCache directive has a duration of 60 seconds but the output Cache API sets a duration of 30 seconds, the page will be cached for only 30 seconds. (The same is true of the other settings as well.)

• Sliding expiration is usually the recommended approach simply because setting all the pages to expire simultaneously, such as at midnight, would cause the server to re-execute all those pages at midnight, potentially putting an unnecessary load on the server.

• Setting the Boolean value to true for VaryByParams or VaryByHeaders indicates that the output cache is to be varied by the parameter or header. Programmatically, you can decide not to vary by that particular parameter or header later in the processing of the page execution, and false could be set to indicate this behavior.

• The Pragma: no-cache HTTP header is not officially an HTTP version 1 behavior and is replaced in HTTP 1.1 with the Cache-Control header. However, like many characteristics of HTTP, the standard is only loosely followed. Nearly all browsers still use Pragma: no- cache and thus ASP.NET must know how to process it.

• When using the page output Cache APIs, always set SetValidUntilExpires to true unless you want clients to be able to remove your output cached pages from memory. The output cache is a performance enhancement, and if clients can arbitrarily remove pages from the cache, performance suffers.

• In the 2.0 version of ASP.NET, we’ll add a AddCacheDependency method to allow you to add an instance of CacheDependency directly.

• No race condition exists when creating a dependency. If the dependent item changes before the item is inserted into the cache, the insert fails and the item is not added to the cache.

• If the page you are output caching relies upon file resources other than those used to execute the page, use the output Cache APIs and make the page dependent upon those files. If the files change, the output cached page will be evicted from the output cache.

• Use cache key dependencies where caching is used to enforce behaviors throughout your application. Dependencies do have additional overhead, but for scenarios such as those described thus far, dependencies allow for some powerful behaviors. For example, every page could theoretically be dependent upon a common cache key. When an administrator wanted to flush the cache, she would simply need to invalidate the common key. This would then evict all output cached pages from memory.

• Don’t use VaryByParam=“*”, which would also resolve to an unknown HTTP POST parameter name. Instead, use the VaryByControl option.

• Why doesn’t ASP.NET provide a common Application or Cache out- of-process option similar to Session? Unlike Session, which is tied to a specific user, Application and Cache contain application-wide settings that apply, or are available to, all users. Thus, changes to Application or Cache must be propagated immediately. However, there are two problems with this: managing contentions when two applications simultaneously modify the same data; and decreased efficiency with replication—as the number of servers grows, the data gets exponentially more difficult to replicate between servers.

• Cache supersedes all the functionality provided by Application and both simplifies it (because it requires no locking to modify) and provides more advanced functionality (such as expiration, dependencies, and purging of data when necessary).