In this article we’ll discuss Session State Management. If you need session state in ASP.NET, there are three session state modes that you can choose from. Each mode offers varying degrees of performance and scalability as described in the following list:
The in-process state store provides excellent performance and scales well. However, most high volume Web applications run in a Web farm. To be able to scale out, you need to choose between the session state service and the SQL Server state store. With either of these choices, you have to understand the associated impact of network latency and serialization, and you have to measure them to ensure that your application meets its performance objectives. Use the following information to help choose a state store:
To ensure optimized session state performance, follow the guidelines outlined in the following sections.
You incur serialization overhead if you use the StateServer or the SQLServer out-of-process state stores. The simpler the object graph, the faster it should serialize. To minimize serialization costs, use basic types such as Int, Byte, Decimal, String, DateTime, TimeSpan, Guid, IntPtr, and UintPrt. ASP.NET uses an optimized internal serialization method to serialize basic types. Complex types are serialized using a relatively slow BinaryFormatter object. For complex types, you can use the Serializable attribute, or you can implement the ISerializable interface. Using this interface provides you with more precise control and may speed up serialization.
Minimize what you serialize. Disable serialization when you do not use it, and mark specific fields from a serializable class that you want to exclude with the NonSerialized attribute. Alternatively, control the serialization process by using the ISerializable interface.
Only implement the ISerializable interface as a last resort. New formatters provided by newer versions of the .NET Framework and improvements to the framework provided serialization will not be utilized once you take this approach. Prefer the NonSerialized attribute.
If you do not use session state, disable session state to eliminate redundant session processing performed by ASP.NET. You might not use session state because you store simple state on the client and then pass it to the server for each request. You can disable session state for all applications on the server, for specific applications, or for individual pages, as described in the following list:
You can also remove the session state module from <httpModules> to completely remove session processing overhead.
Storing STA COM objects in session state causes thread affinity. Thread affinity severely affects performance and scalability. If you do use STA COM objects in session state, be sure to set the AspCompat attribute of the @ Page directive.
Page requests that use session state internally use a ReaderWriterLock object to manage session data. This allows multiple reads to occur at the same time when no lock is held. When the writer acquires the lock to update session state, all read requests are blocked. Normally two calls are made to the database for each request. The first call connects to the database, marks the session as locked, and executes the page. The second call writes any changes and unlocks the session. For pages that only read session data, consider setting EnableSessionState to ReadOnly: <%@ Page EnableSessionState=”ReadOnly” . . .%>
Setting EnableSessionState to ReadOnly is particularly useful when you use frames. In this event, the default setting serializes the execution of the page because a ReaderWriterLock is used. By setting EnableSessionState to ReadOnly, you avoid blocking, and you send fewer calls to the database. One option is to disable sessions in the configuration file as shown earlier, and to set the ReadOnly attribute on a page-by-page basis.
In our next artice we’ll describe some of the best practices for View State Management.