Recommended way to use asp.net sessions on Azure

Question

I have read a few articles where it says the recommended is dev app fabric cache on azure while others says use universal providers and use sql azure to store session state in a sql azure table. Any pundits out there please let me know which is better and why? The "why" is required so I put my case forward for recommendation.Thanks

Answer 1

Cache has specific limits on transactions/hour, bandwidth/hour, and number of concurrent connections. The transaction and bandwidth thresholds are per clock-hour, so you must remain under these limits. Since price isn't linear, you can estimate your session usage and create a cache one larger than what you need, but it's just something you need to consider.

SQL Azure, via universal providers, won't have such a limitation. I don't know your cache storage requirements, but if the cache is under 100MB, you're now talking about a $5 monthly cache, vs. minimum $45 for the Cache service. And if you needed the full 4GB Cache space, a 5GB SQL Azure Cache would be significantly less expensive.

Having said all that: The Cache provider has a specific usage target. For instance: the 4GB cache supports up to 12.8 million transactions per hour, or over 3,500 per second. Even the 128MB cache providers over 100 transactions per second.

So: I'd look at the decision with two basic criteria:

• If cost is a factor, and you believe your cache transaction rate and data volume can be handled by SQL Azure, then SQL Azure seems to be your best bet (and will scale to sizes far beyond the 4GB max of the Cache service). There's no published transaction rate information around SQL Azure, but you can probably do some simple tests to see how many session hits you can push per second before you see degraded performance.
• If your app demands a very high transaction rate, the Cache's published transaction targets point to Cache as the better solution. Note: You probably can't generate something like 3,500 transactions per second against Cache from a single instance; this is more of a multi-instance scenario.

For more information on Cache specifics, see here.

EDIT Aside from SQL and Shared Cache, you can now configure your own dedicated cache, either using memory from existing roles (costing you nothing) or with a cache role within your deployment (costing whatever the role instances cost). This is the fastest option, since it's colocated with your deployment. It also supports the memcached protocol. More information can be found here.

Answer 2

This good article describes the advantages and disadvantages of three different session state management in Azure: sessions in azure