iamkrillin
iamkrillin

Reputation: 6876

How does windows azure websites handle session?

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

Answers (5)

Syri
Syri

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

cory-fowler
cory-fowler

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

Jordi
Jordi

Reputation: 2797

You have some options to solve this problem

  1. sql solution

  2. table storage solution

  3. 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

Steve Morgan
Steve Morgan

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

Rikon
Rikon

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

Related Questions