Reputation: 6876
I was investigating one of the new offerings in windows azure. Specifically "Websites" and i'm not able to find anything about how it handles session data. Does anybody know? I moved the slider up to 2 instances and it all seems to "just work", but I would feel better about using it if I knew for sure it was sharing session data (or not?)
Upvotes: 5
Views: 4093
Reputation: 671
Since the linked video above is quite out of date, I thought I would share what I was able to find regarding sessions on Azure.
Azure makes use of Application Request Routing.
ARR cleverly keeps track of connecting users by giving them a special cookie (known as an affinity cookie), which allows it to know, upon subsequent requests, to which server instance they were talking to. This way, we can be sure that once a client establishes a session with a specific server instance, it will keep talking to the same server as long as his session is active.
Reference: https://azure.microsoft.com/en-us/blog/disabling-arrs-instance-affinity-in-windows-azure-web-sites/.
Upvotes: 2
Reputation: 4088
If you'd like to learn more about the architecture of Windows Azure Web Sites, I would suggest watching this session from TechEd 2012 Windows Azure Web Sites: Under the Hood
Upvotes: 4
Reputation: 2797
You have some options to solve this problem
sql solution
table storage solution
memcache solution
Sql is the classic solution. Sql handles all sessions with classic sql requests.
Table storage works wonders (in my experience). It's really easy to scale and really simple to implement (just a few lines of code on your webconfig).
Memcache solution is the best solution. Azure provides a cluster of "cache servers" to store session (or other serializable objects). It's really easy to scale and works really really fast. I am using this solution on my production environments with 0 problems and a really good performance results.
In order to implement Memcache, you just need to add those lines on your web.config:
<configuration>
<configSections>
<section name="dataCacheClients" type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere"/>
<!-- more config sections here -->
</configSections>
<dataCacheClients>
<dataCacheClient name="default">
<hosts>
<host name="YOUR_NAME_HERE.cache.windows.net" cachePort="YOUR_PORT_HERE"/>
</hosts>
<securityProperties mode="Message">
<messageSecurity authorizationInfo="YOUR_KEY_HERE">
</messageSecurity>
</securityProperties>
</dataCacheClient>
</dataCacheClients>
<!-- more configurations here -->
Summary
If you don't care about the costs and you wish to archieve best performance possible, go for memcache solution. If you need to keep your costs really low, go for table storage.
Upvotes: 4
Reputation: 13091
Are you targetting ASP.NET 4.5?
If you don't explicitly configure any providers with 4.5, it will default to using the ASP.NET Universal Providers which are now included in Machine.config. So it will be using a SQL Session State provider by default. I would expect it to use a local DB, though, so I'm not sure how it would be sharing the state.
You could test it by opening up some sessions, then taking the number of instances back down to one and see if some sessions lose state or not.
The load balancer could be using session affinity, in which case, you might not notice if it's not sharing session state.
Upvotes: 1
Reputation: 2696
How many web roles do you have? If you keep it to 1 you should be ok, but you can read the details here about how multiple web roles are going to create the same session state problems you'd encounter if you were running a web farm... When running a web farm an option is keeping session state in your db. So as you can imagine, if you needed to run multiple web roles then you could lean on sql Azure (though Table Storage is really cool, and likely a great fit for something like session state)
But to more directly answer your question, you can use multiple web roles to distribute processing load, and a web role is just a "front-end web application and content hosted inside of IIS". So again, if you're only using one web role then your app probably is working just fine. But just be aware that if you ever need to scale your web roles out, it will bork your Session persistence up.
Upvotes: -1