State Management Best Practices

Saturday, February 7, 2009


 

The following table highlights the main state management issues:

 

State Management Issues

Implications

Stateful components

Holds server resources and can cause server affinity, which reduces scalability options.

Use of an in-memory state store

Limits scalability due to server affinity.

Storing state in the database or server when the client is a better choice

Increased server resource utilization; limited server scalability.

Storing state on the server when a database is a better choice

In-process and local state stored on the Web server limits the ability of the Web application to run in a Web farm. Large amounts of state maintained in memory also create memory pressure on the server.

Storing more state than you need

Increased server resource utilization, and increased time for state storage and retrieval.

Prolonged sessions

Inappropriate timeout values result in sessions consuming and holding server resources for longer than necessary.

 

 

Some of the best practices adopted for effective state management are as under:

 

Minimize Session Data

Keep the amount of session data stored for a specific user to a minimum to reduce the storage and retrieval performance overheads. The total size of session data for the targeted load of concurrent users may result in increased memory pressure when the session state is stored on the server, or increased network congestion if the data is held in a remote store.

If you use session state, there are two situations you should avoid:

●    Avoid storing any shared resources. These are required by multiple requests and may result in contention because the resource is not released until the session times out.

●    Avoid storing large collections and objects in session stores. Consider caching them if they are required by multiple clients.

 

Free Session Resources As Soon As Possible

Sessions continue to hold server resources until the data is explicitly cleaned up or until the session times out.

You can follow a two-pronged strategy to minimize this overhead. At design time, you should ensure that the session state is released as soon as possible. For example, in a Web application, you may temporarily store a dataset in a session variable so that the data is available across pages. This data should be removed as soon as possible to reduce load. One way to achieve this is to release all session variables containing objects as soon as the user clicks on a menu item.

 

Avoid Accessing Session Variables from Business Logic

Accessing session variables from business logic makes sense only when the business logic is interspersed along with presentation code as a result of tight coupling.

However, in the majority of cases, you benefit from loosely coupled presentation and business logic, partitioned in separate logical layers. This provides better maintainability and improved scalability options. It is most frequently user interface-related state that needs to be persisted across calls. Therefore, session-related state should be part of the presentation layer. In this way, if the workflows of the user interface change, it is only the presentation layer code that is affected.

Do You Know the Number of Concurrent Sessions and Average Session Data per User?

Knowing the number of concurrent sessions and the average session data per user enables you to decide the session store. If the total amount of session data accounts for a significant portion of the memory allocated for the ASP.NET worker process, you should consider an out-of-process store.

Using an out-of-process state store increases network round trips and serialization costs, so this needs to be evaluated. Storing many custom objects in session state or storing a lot of small values increases overhead. Consider combining the values in a type before adding them to the session store.

Filed Under: Architecture, ASP.NET

Add comment

biuquote
Loading