I missed that, thanks. So if our code isn't using session and isnt using the TempDataProvider, are we fine with turning off session state? Or does umbraco need it for something?
I think that you are but I've not tested it myself as we almost always have some TempData somewhere. For Azure we always use the Redis Session State provider, it's very easy to setup and very quick.
Hi Jeavon, I'm interested to know which tier of the Redis Cache you use? It seems that if you go for "Standard" (the first tier that is "Production-ready") and also go for the C2 plan (the first which is not "Low" network performance) then that will cost in the region of £103 per month. We wanted to implement Redis but that cost quickly put us off. I can see you can get a basic/low option for £10 per month but I can't imagine this will be reliable.
I think a Standard C0 (approx £30 pcm) is fine for most websites requiring session state for TempData or basic logins. What is very important to get right is the timeouts when using the provider, below are the settings we have found to be optimal.
If we use the Microsoft.Web.Redis.RedisSessionStateProvider as shown above and have "<sessionState mode="Custom" customProvider="AzureRedisSessionStateStore">" do we have to do any fancy coding or does it just take over the old fashioned session and cache destinations for us? i.e. no change to code required
You don't need to do anything different, it's "just" another session state provider. But, as with the SQL provider any object you put into the session must be serializable.
Azure web app + load balancing + Session state
Based on this blog post from Microsoft, we should be using a shared caching strategy for session state if we are load balancing umbraco on azure web apps, https://azure.microsoft.com/en-us/blog/scalable-umbraco-cms-solution-for-azure-web-apps/. I don't see any mention of this on the umbraco load balancing documentation, https://our.umbraco.org/documentation/Getting-Started/Setup/Server-Setup/load-balancing/flexible.
What should we do?
It's in the "Common load balancing setup information" section on this page
I missed that, thanks. So if our code isn't using session and isnt using the TempDataProvider, are we fine with turning off session state? Or does umbraco need it for something?
I think that you are but I've not tested it myself as we almost always have some TempData somewhere. For Azure we always use the Redis Session State provider, it's very easy to setup and very quick.
Hi Jeavon, I'm interested to know which tier of the Redis Cache you use? It seems that if you go for "Standard" (the first tier that is "Production-ready") and also go for the C2 plan (the first which is not "Low" network performance) then that will cost in the region of £103 per month. We wanted to implement Redis but that cost quickly put us off. I can see you can get a basic/low option for £10 per month but I can't imagine this will be reliable.
Those numbers are pulled from here: https://azure.microsoft.com/en-gb/pricing/details/cache/
Cheers, James.
Hi James,
I think a Standard C0 (approx £30 pcm) is fine for most websites requiring session state for TempData or basic logins. What is very important to get right is the timeouts when using the provider, below are the settings we have found to be optimal.
There is more detail on this here
Hope that's helpful.
Jeavon
Cool, thanks Jeavon. Can you use the same Redis Cache for multiple websites?
Yes, it hasn't occurred to me but I suppose you could. Azure Redis comes with 16 databases, so I would specify a different DB for each site.
Just add the following attribute
Nice. Makes it a bit more economical if we can spread that cost. Thanks again.
If we use the Microsoft.Web.Redis.RedisSessionStateProvider as shown above and have
"<sessionState mode="Custom" customProvider="AzureRedisSessionStateStore">
" do we have to do any fancy coding or does it just take over the old fashioned session and cache destinations for us? i.e. no change to code requiredTIA
Craig
You don't need to do anything different, it's "just" another session state provider. But, as with the SQL provider any object you put into the session must be serializable.
is working on a reply...