The following table highlights the main state management
State Management Issues
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
Inappropriate timeout values result in sessions consuming
Some of the best practices adopted for effective state
management are as under:
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.
Resources As Soon As Possible
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.
Session Variables from Business Logic
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.
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.