Web Application Performance Design Inspection Questions - State Management

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


State Management Issues



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.

To assess the state management efficiency, review the following questions:

  • Do you use stateless components?
  • Do you use .NET remoting?
  • Do you use Web services?
  • Do you use Enterprise Services?
  • Have you ensured objects to be stored in session stores are serializable?
  • Do you depend on view state?
  • Do you know the number of concurrent sessions and average session data per user?

Do You Use Stateless Components?

Carefully consider whether you need stateful components. A stateless design is generally preferred because it offers greater options for scalability. Some of the key considerations are the following:

What are the scalability requirements for your application?

If you need to be able to locate your business components on a remote clustered middle tier, you may either need to plan for stateless components, or store state on a different server that is accessible by all of the servers in your middle-tier cluster.

If you do not have such scalability requirements, stateful components in certain scenarios help improve performance, because the state need not be transmitted by the client over the wire or retrieved from a remote database.

How do you manage state in stateless components?

If you design for stateless components and need to abstract state management, you need to know the lifetime requirements and size of the state data. If you opt for stateless components, some options for state management are the following:

  • Passing state from the client on each component call. This method is efficient if multiple calls are not required to complete a single logical operation and if the amount of data is relatively small. This is ideal if the state is mostly needed to process requests and can be disposed of once the processing is complete.
  • Storing state in a database. This approach is appropriate if the operation spans multiple calls such that transmitting state from the client would be inefficient, the state is to be accessed by multiple clients, or both.

Do You Use .NET Remoting?

.NET remoting supports server-activated objects (SAOs) and client-activated objects (CAOs). If you have specific scalability requirements and need to plan for a load-balanced environment, you should prefer single call SAOs. These objects retain state only for the duration of a single request.

Singleton SAOs may be stateful or stateless and can rehydrate state from various mediums, depending on requirements. Use these when you need to provide synchronized access to a particular resource.

If your scalability objectives enable you to use a single server, you can evaluate the use of CAOs, which are stateful objects. A client-activated object can be accessed only by the particular instance of the client that created it. Hence, they are capable of storing state across calls.

For more information, see Remoting (.NET 1.1) Performance Guidelines.

Do You Use Web Services?

Stateful Web services signify a RPC or distributed object design. With RPC-style design, a single logical operation can span multiple calls. This type of design often increases round trips and usually requires that state is persisted across multiple calls.

A message-based approach is usually preferable for Web services. With this approach, the payload serves as a data contract between the client and the server. The client passes the payload to the server. This contains sufficient information to complete a single unit of work. This generally does not require any state to be persisted across calls, and, as a result, this design can be easily scaled out across multiple servers.

For more information, see Web Services (ASMX 1.1) Performance Guidelines - State Management.

Do You Use Enterprise Services?

If you plan to use Enterprise Services object pooling, you need to design stateless components. This is because the objects need to be recycled across various requests from different clients. Storing state for a particular client means the object cannot be shared across clients.

For more information, see Enterprise Services (.NET 1.1) Performance Guidelines - State Management.

Have You Ensured Objects to be Stored in Session Stores are Serializable?

To store objects in an out-of-process session state store, such as a state service or SQL Server, the objects must be serializable. You do not need serializable objects to store objects in the in-process state store, but you should bear this in mind in case you need to move your session state out-of-process.

You enable a class to be serialized by using the Serializable attribute. Make sure that you use the NonSerialized attribute to avoid any unnecessary serialization.

Do You Depend On View State?

If you use or plan to use view state to maintain state across calls, you should prototype and carefully evaluate the performance impact. Consider the total page size and the bandwidth requirements to satisfy your response time goals.

Persisting large amounts of data from server controls, such as the DataGrid, significantly increases page size and delays response times. Use tracing in ASP.NET to find out the exact view state size for each server control or for a whole page.

More Information

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.

Personal tools