ASP.NET 2.0 Performance Inspection Questions - Session State

From Guidance Share

Jump to: navigation, search

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


Contents

Do you disable session state when not required?

Session state is on by default. If your application does not use session state, disable it in Web.config as follows.


  <sessionState mode="Off" />


If parts of your application need session state, identify pages that do not use it and disable it for those pages by using the following page level attribute.


  <@% EnableSessionState = "false" %>


Minimizing the use of session state increases the performance of your application.


Do you have pages that do not write to a session?

Page requests using session state internally use a ReaderWriterLock to manage access to the session state. For pages that only read session data, consider setting EnableSessionState to ReadOnly.


  <%@ Page EnableSessionState="ReadOnly" . . .%>


This is particularly useful when you use HTML frames. The default setting (due to ReaderWriterLock) serializes the page execution. By setting it to ReadOnly, you prevent blocking and allow more parallelism.


Do you check for nulls before accessing items in session state?

You can improve performance by checking for null before accessing the item, as shown in the following code.


  object item = Session["myitem"];
  if(item==null)
  {
  // do something else
  }


A common pitfall when retrieving data from session state is to not check to see if the data is null before accessing it and then catching the resulting exception. You should avoid this because exceptions are expensive. To find where your code accesses session state, you can search for the string "Session."


Do you store complex objects in session state?

Avoid storing complex objects in session state, particularly if you use an out-of-process session state store. When using out-of-process session state, objects have to be serialized and deserialized for each request, which decreases performance.


Do you store STA COM objects in session state?

Storing single-threaded apartment (STA) COM objects in session state causes thread affinity because the sessions are bound to the original thread on which the component is created. This severely affects both performance and scalability.

Make sure that you use the following page level attribute on any page that stores STA COM objects in session state.


  <@%Page AspCompat = "true" %> 

This forces the page to run from the STA thread pool, avoiding any costly apartment switch from the default multithreaded apartment (MTA) thread pool for ASP.NET. Where possible, avoid the use of STA COM objects.

For more information, see Knowledge Base article 817005, "FIX: Severe Performance Issues When You Bind Session State to Threads in ASPCompat Model" at http://support.microsoft.com/default.aspx?scid=kb;en-us;817005.


Related Items

For more information about the questions and issues raised in this section, see ASP.NET 2.0 Performance Guidelines - Session State

Personal tools