Overview

ASP.NET today is widely used for high traffic web applications that need to handle millions of users and are deployed in load balanced web farms. ASP.NET View State is a very powerful mechanism that stores pages, controls and custom values between multiple HTTP requests across client and the web server. View State is ASP.NET method for persisting page and control states during post-backs. All ASP.NET applications have to deal with view state which is becoming a performance overhead. View State caching helps caching view state on web servers and send a much smaller payload to the user's browser containing only a unique ID for this view state. As a result, the page uses lesser bandwidth which improves performance and the ASP.NET application also scales much better.

Why Cache View State?

There are multiple downsides to View State. As it is known View State is an encrypted text string containing the state of web form controls and widgets and is sent to the user's browser to preserve the state across post-backs. For forms with lot of controls, DataGrid control, or some other complex controls, the View State can become quite large.

Another reason can be of heavy ASP.NET View State where the increased bandwidth usage increases the bandwidth cost considerably. For example, if for each HTTP requests, about 60-100k of additional ASP.NET View State data is appended, this multiplied by the total number of transactions and it is clear that bandwidth consumption becomes very high.

Also, in some situations, there is a security risk with sending confidential data as part of ASP.NET View State. And, encrypting it before sending is also costly.

Here are some reasons why it should be considered to cache the View State.

View State is large (tens of KB) on large forms and DataGrid.
Large View State slows down page download time.
Large View State slows down post-back request time.
Cache View State on web servers & send only a token to user.
View State cache is distributed to all web servers in the farm; there is no single point of failure.

NCache's View State Caching resolves these issues, following are some of its features:

Increased Performance: NCache reduces the request/response payload which improves the overall request time.

Availability and Reliability: NCache is in-memory cache, it is distributed and synchronized across all web servers, even if the post-back request goes to a different web server in the farm than the original server where the viewstate was created, NCache is able to find the viewstate value in the cache.

View State with its Session: NCache allows view state to be categorized with respect to its respective session.

Limit View State Caching: For longer sessions with abundant amount of viewstates it is now possible to limit viewstate per session to a configurable number. Metadata is used for limiting, meta data is also cached. It is also possible to lock metadata. Locking can be configured via web.config.

Page level Grouping for View State: NCache allows grouping on page level, multiple pages can be coupled to define a group. For each group, different configurations can be set.

ViewState.xml is required for view state grouping feature. This xml can have multiple web app configurations. In each web app configuration, there can be one or more group configurations. And different caches can be configured for different groups.

Send comments on this topic.