ASP.NET Session State and Velocity Provider

ASP.NET session state supports several different storage options for session data. Below is a quick summary of the different modes of session state and their pros and cons

• InProc
  • Stores session state in memory on the web server.
  • Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.
  • Cannot be used with web farms.
  • Session state will be lost if the worker process (aspnet_wp.exe) recycles, or if the AppDomain restarts.
• StateServer
  • Stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the web application is restarted and also makes session state available to multiple web servers in a web farm.
  • Objects are serialized to an out of process memory store. The cost of serialization/deserialization can affect performance if you’re storing lots of objects.
  • Solve the session state loss problem in InProc mode. Allows a web farm to store session on a central server.
  • Single point of failure at the State Server.
  • For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm.
• SQLServer
  • Stores session state in a SQL Server database. This ensures that session state is preserved if the web application is restarted and also makes session state available to multiple web servers in a web farm.
  • Solve the session state loss problem in InProc mode. Allows a web farm to store session on a central server.
  • Session state data can survive a SQL server restart, and you can also take advantage of SQL server failover cluster, after you’ve followed instructions in KB 311029.
  • For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm.

The best scalability is provided by SQLServer session store but it comes with a slight performance cost. The best performance is provided by InProc session store but it cant really be used in any production web app because of scalability issues.

What if you could have the scalability of SQLServer session store but with the performance of InProc / StateServer session state? "Velocity" is a distributed caching product to provide the .NET application platform support for developing highly performant, scalable, and highly available applications. It allows any type of data CLR object, XML document, or binary data to be cached. Velocity fuses large numbers of cache nodes in a cluster into a single unified cache and provides transparent access to cache items from any client connected to the cluster.

Velocity provides a session store provider that allows you to store your ASP.Net Session object in Velocity cache – This enables non-sticky routing allowing scaling your application.

Hooking up Velocity in your ASP.NET web app is easy. All it takes is some web.config entries:

1. Configure session state provider element in your app’s web.config file:

<sessionState mode="Custom" customProvider="SessionStoreProvider">
    <providers>
        <add name="SessionStoreProvider" type="System.Data.Caching.SessionStoreProvider, ClientLibrary"/>
    </providers>
</sessionState>

2. Configure Velocity client configuration elements in web.config:

<configSections>
    <section name="dcacheClient" type=" System.Configuration.IgnoreSectionHandler" allowLocation="true" allowDefinition="Everywhere"/>
</configSections>
<dcacheClient deployment="simple" localCache="false">
    <hosts>
        <!--List of hosts -->
        <host name="<serviceHostName>" cachePort="22233" cacheHostName="DistributedCacheService"/>
    </hosts>
</dcacheClient>

Note : “serviceHostName” is the hostname where distributed cache service is running on cache port “22233”(default setting). Configure these 2 parameters appropriately.

3. Add reference to or copy to \bin folder the following dll’s that the session store provider uses: CacheBaseLibrary.dll, FabricCommon.dll, ClientLibrary.dll, CASBase.dll, CASClient.dll .

And that’s about it; your web application is ready to run with the Velocity SessionStoreProvider. 

Note:

• For Velocity Session State provider to work, Cache cluster should be up and running. To learn about to how to deploy Velocity Distributed Cache Cluster, please refer the product documentation.
• As the provider stores the session objects in out-of-proc distributed cache service, objects that you put in Session should be serializable.

For more info please refer to the product documentation or the Velocity blog on MSDN How to Use Session State Provider (Microsoft Project code named Velocity)

Technorati Tags: SessionState,Velocity,Distributed Cache