Session State Management in Windows Azure Web Roles
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