Session State Investigation
Article on Session state best practices
http://msdn.microsoft.com/msdnmag/issues/05/09/sessionstate/default.aspx
Due to the stateless nature of the HTTP protocol, Web applications have always shouldered the burden of user state management. This investigation looks at the all the ways ASP.NET provides a number of ways to maintain user state, and make it conform to Deepthought. This feature provides a convenient programmatic interface for associating arbitrary application state with a user session, and takes care of back-end state storage and client session management for the application.
How Session State Works
ASP.NET session state lets you associate a server-side string or object dictionary containing state data with a particular HTTP client session. A session is defined as a series of requests issued by the same client within a certain period of time, and is managed by associating a session ID with each unique client. The ID is supplied by the client on each request, either in a cookie or as a special fragment of the request URL. The session data is stored on the server side in one of the supported session state stores, which include in-process memory, SQL Server™ database, and the ASP.NET State Server service. The latter two modes enable session state to be shared among multiple Web servers on a Web farm and do not require server affinity (that is, they don't require the session to be tied to one specific Web server).
Improving Performance
Using session state in an ASP.NET application can add noticeable overhead to the application performance. This should be expected as you are executing more code during the processing of every request in the application and possibly making network requests to retrieve stored state.
The InProc session state mode is the fastest of the built-in state storage modes. Its overhead is limited to extracting the session ID from the request, performing a cache lookup for the state dictionary stored in the application's memory space, and marking the session as accessed to prevent its expiration. Updates to the data contained in the session are made directly to objects in memory and do not require any additional work to be persisted for the next request. (This is what we are doing now)
However, because the InProc mode lacks the application restart tolerance and does not work in Web farm scenarios, the application frequently has no choice but to use one of the other two out-of-process modes.
In the default out-of-process modes, SQLServer and StateServer, session state must be fetched from an external store and deserialized from its binary blob representation to the in-memory state dictionary form in the AcquireRequestState stage. In the ReleaseRequestState stage, the state dictionary needs to be serialized again and transferred to external storage. In addition, the session entry in the store must be updated to indicate the last access time to prevent its expiration. In these modes, serialization and deserialization of the state data, and its out-of-process transfer, are by far the most expensive operations introduced by session state to the request path.