Freigeben über

Session State Management in Windows Azure Web Roles

  • Artikel

One of the frequent questions that developers and customers ask me during my Windows Azure related discussion is how to manage session state in Windows Azure Web Role. With Web Roles supporting full IIS (previously it was just hosted web core), the inclination to fall back to the tried and tested methods of either in-proc where the session is stored in the webserver memory or store it in SQL Server is very tempting. A few queries also hover around out-of proc and storing them in State Server.

 But these not based on the design principles of Azure framework primarily due to the following reasons

a) There are no sticky sessions in Azure and the load balancer does a round robin routing to the instances

b) An instance can get recycled due to a host or guest upgrade apart from the regular code updates.

 We recommend the following ways to store sessions in Windows Azure web roles

 a) Table Storage with the Table Storage Provider ()

 b) SQL Azure with ASP.Net Universal Provider

 c) Windows Azure Cache with Dedicated Cache Role

Table Storage

=========================

Table Storage Provider is a subset of the Windows Azure ASP.NET Providers written by the Windows Azure team. The Table Storage Session Provider is, in fact, a custom provider that is compiled into a class library (.dll file),     

enabling developers to store session state inside Windows Azure Table Storage. 

The way it actually works is to store each session as a record in Table Storage. Each record will have an expired column that describe the expired time of each session if there’s no interaction from the user.

 Advantage

The single biggest advantage of using Table storage is cost. The cost associated with storage is miniscule compared all other options. It is about $0.09 per GB per month for storage capacity and $0.10 per 1,000,000 storage transactions.

 Disadvantage

 One of the likely disadvantages of Table Storage Session Provider is that it may not perform as fast as the other options discussed below. Since it's file based. You have to write extra code but with the API it’s significantly less cumbersome with the Client APIs than dealing with raw rest calls.

This session state provider is provided on an as-is basis as a code sample and as such it is not supported by Microsoft.

Web.Config Changes

The following code snippet should be applied in web.config when using Table Storage Session Provider.

<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">

<providers>

<clear/>

<add name="TableStorageSessionStateProvider" type="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider" />

</providers>

</sessionState>

Details

https://code.msdn.microsoft.com/windowsazure/Windows-Azure-ASPNET-03d5dc14#content

Code Sample   

https://code.msdn.microsoft.com/windowsazure/Windows-Azure-ASPNET-03d5dc14/view/SourceCode#content

 

SQL Azure

========================

 SQL Azure can also be used as storage for session state by using the ASP.Net Universal Providers. You will need to apply the following code snippet in web.config when using SQL Azure Session Provider:

 <sessionState mode="SQLServer"

  sqlConnectionString="Server=tcp:[serverName].database.windows.net;Database=myDataBase;User ID=[LoginName]@[serverName];Password=[myPassword];Trusted_Connection=False;Encrypt=True;"

  cookieless="false" timeout="20" allowCustomSqlDatabase="true" />

Advantage

The advantage of using SQL Azure as session provider is that it’s cost effective, especially when you have an existing SQL Azure database. It performs better than Table Storage Session Provider in most cases. Database rows are persistent so even if the role are recycled or rebooted the data would be persisted.

Disadvantage

It requires the developer to clean the expired session manually by calling the DeleteExpiredSessions stored procedure. Since SQL Azure doesn't have a SQL Agent running it needs to be scheduled via a Maintenance plan running on premise or needs to be triggered via a worker role. Another drawback of using SQL Azure as session provider is that Microsoft does not provide any official support for this. Also SQL Azure being a shared dense database architecture there are no performance SLAs and the queries may fail which will require re-trying the queries again. In a low latency scenario like session management it may not be the best choice available.

Details

 https://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx

Download

  https://nuget.org/packages/System.Web.Providers

 

Windows Azure Role Based Cache 

========================================

Windows Azure Role Based Caching is likely the best option available today. It provides a high-performance, in-memory, dedicated caching service. The Windows Azure session state provider is an out-of-process storage mechanism for ASP.NET applications. Accessing RAM is very much faster than accessing disk or file based system, so Windows Azure Role Based Caching obviously provides the highest performance access of all the available options.

You can either allocate memory either from the same instance or allocate it on a worker roles solely hosted for the purpose of storing sessions. In general, a dedicated Caching role provides the best performance, because it does not share the role's virtual machine with any other application services. It also provides the most flexibility, because you can scale the Caching role independently. For these reasons, using a dedicated topology is the recommended Caching architecture.

Advantage

The advantage of using Windows Azure Caching is that it performs best as far as performance is concerned. It's also flexible and you can just spawn another instance if you need to have more cache in case of dedicated or allocate more space in case of co-located. There is also a capacity planning guide which assists in deciding how much cache size should be used on the roles.

Disadvantage

 If the option of dedicated role is chosen then there is the extra cost associated with these compute instances. It’s also recommended to have at-least 3 instances of the cache worker role for high availability so it adds up to the cost of running the service.

Details

   https://msdn.microsoft.com/en-us/library/windowsazure/hh914140.aspx

Sample

   https://msdn.microsoft.com/en-us/library/windowsazure/jj131262.aspx

Capacity Planning

   https://msdn.microsoft.com/en-us/library/windowsazure/hh914129.aspx

 I hope the material above would provide you with some insights to identify which is the best solution for the application keeping the technical and cost requirements in account.

 

Angshuman Nayak , Escalation Services, Cloud Integration Engineering

Comments

  • Anonymous
    July 14, 2013
    Thanks for the information.If I use role-based caching, what happens to the session state during VIP swap? How are online users affected?Is it possible to configure the cache in a different service, so it survives this kind of changes?

  • Anonymous
    July 18, 2013
    Hi duduzar,The cache workers roles should be a part of your cloud service. So the WebRoles and Cache Worker roles move together when a VIP swap is done.  In case you are using co-located cache  they anyway form a part of the same instance the WebRole is using and in this case also they move together. May be I am not getting your question correctly. It would be great if you can providea little more detail.  

  • Anonymous
    November 26, 2013
    I think duduzar's point is that when using in-role caching for session state, sessions will not persist across deployments.  With shared caching or the new cache service, sessions can persist even after a deployment/swap VIP.  Is this correct?

  • Anonymous
    February 20, 2014
    Very informative. Thanks for the article.

  • Anonymous
    October 07, 2015
    There is now the Azure Managed Cache Service option for Session State storage: azure.microsoft.com/.../cache-dotnet-how-to-use-service

  • Anonymous
    November 09, 2016
    Can we use Azure table storage for session management in ASP.net with latest Azure Storage client library?The examples we found are with Azure Storage client library version 1.7 which is very old.Found some link suggesting not to use Azure table storage for session management.https://codingamuseme.wordpress.com/2014/11/04/table-storage-session-provider-for-azure-is-now-obsolete-prefer-sql-server-for-session-state-as-its-easy/http://sanganakauthority.blogspot.in/2014/08/session-management-using-sql-azure-and.htmlPlease suggest.