The following table highlights the main state management
issues:
State Management Issues |
Implications |
Stateful components |
Holds server resources and can cause server affinity, |
Use of an in-memory state store |
Limits scalability due to server affinity. |
Storing state in the database or server when the client |
Increased server resource utilization; limited server |
Storing state on the server when a database is a better |
In-process and local state stored on the Web server |
Storing more state than you need |
Increased server resource utilization, and increased time |
Prolonged sessions |
Inappropriate timeout values result in sessions consuming |
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.