Improving ASP.NET Performance Part 9: State Management

In this article we’ll discuss state management. Web applications present specific challenges for state management. This is especially true for Web applications that are deployed in Web farms. There are several different types of state:

·         Application state. Application state is used for storing application-wide state for all clients. Using application state affects scalability because it causes server affinity. In a Web scenario, if you modify application state, there is no mechanism to replicate the changes across servers. Therefore, if a subsequent request from the same user goes to another server, the change is not available. You store data in application state by using a key/value pair, as shown in the following sample.

Application[“YourGlobalState”] = somevalue;

·         Session state. Session state is used for storing per-user state on the server. The state information is tracked by using a session cookie or a mangled URL. ASP.NET session state scales across Web servers in a farm.

·         View state. View state is used for storing per-page state information. The state flows with every HTTP POST request and response.

·         Alternatives. Other techniques for state management include client cookies, query strings, and hidden form fields.

We’ll discuss the guidelines that are specific to application state, session state, and view state in follow-up articles. The following are guidelines that address the broad issues that concern state management in general:

·         Store simple state on the client where possible.

·         Consider serialization costs.

Store Simple State on the Client Where Possible

Use cookies, query strings, and hidden controls for storing lightweight, user-specific state that is not sensitive such as personalization data. Do not use them to store security-sensitive information because the information can be easily read or manipulated.

·         Client cookies. Client cookies are created on the server, and they are sent and stored on the client browser. They are domain specific and are not completely secure. All subsequent requests from a browser include the cookies, which the server code can inspect and modify. The maximum amount of data that you can put in cookie is 4 KB.

·         Query strings. Query strings are the data that is appended to a URL. The data is clear text and there is a limit on the overall string length. The data can easily be manipulated by the user. Therefore, do not retrieve and display sensitive data based on query parameters without using authentication or validation. For anonymous Web sites, this is less of an issue.

·         Hidden controls. Hidden controls on the page store state information that is sent back and forth in requests and responses.

Consider Serialization Costs

If you need to serialize state, consider the serialization costs. For example, you might want to serialize state to store in a remote state store. Only store what is absolutely necessary, and prefer simple types rather than complex objects to reduce the impact of serialization.

In our next article we’ll talk about Application State, followed by Session, and View State.