I have a MVC3, ASP.NET 4.5 web application deployed on Azure Websites, using SQL Azure.
Currently I am using some "inproc" Session variables which I need to remove since I am going to start using multi website instances. I could just store the Session variable values in the SQL Azure DB, but I am also using TempData, which also uses Session state, "under the bonnet". Due to TempData use, I do need to implement an "out of proc" session solution.
I have seen some recommendation for using AppFabric caching, but I am unsure whether this is still current, and whether it is correct for Azure websites.
Also my development setup is on a Windows 7 machine with SQL Server 2008 R2. So a solution should be transferable with minimum pain.
There is also a "thread agility" issue with session variables, and a open source solution has been created using REDIS caching, but I have no experience of this, or REDIS. See: GitHub site
So thoughts I have are:
1) Angieslist/AL-redis custom provider, see: GITHUB link . Not entirely sure that this can be used in a Azure Websites application.
2) Appfabric. Not sure if this is relevant or current for Azure Websites.
3) SQL Azure session provider.
4) Azure Table storage.
5) Use a custome TempData provider to persist via cookies ie https://www.nuget.org/packages/BrockAllen.CookieTempData.dll/1.2.2, and then remove other session variables.
I would be very grateful for advice on a good Azure Websites session implementation mechanism which is simple. My data is pretty simple. I think I have one object which I quess I will need to serialize, probably via Json.NET
If you have more than one instance of an Azure Web Site, sticky sessions are enabled by default by the load balancer. This means that a user will be directed to the same instance (server) and that you'll be able to use session state in your app.
You may also find the Distributed Caching section (Ch 12) of this ebook helpful http://aka.ms/CloudApps_PDF
Related
I need to know the best practices for deploying a new version of an ASP.NET MVC application while users are still connected to it
Everytime one deploys the .dll that contains the models and controllers of the application, the application is rebooted. Also deploying the web.config (that references eventually new libraries) results in rebooting the application.
So, the question is: how do I update the application's dll or web.config without disconnecting the users from the site?
You want to use another session state option other than using in-proc so your users survive when the process recycles or system reboots.
InProc: In-Proc mode stores values in the memory of the ASP.NET worker process. Thus, this mode offers the fastest access to these values. However, when the ASP.NET worker process recycles, the state data is lost.
See ASP.NET Session State Options for more ASP.NET options and mentions of other third party session state providers.
This question also deals with possible deployment scenarios to help with the websites under load and slow app times after a pool recycle: How are people solving app pool recycle issues on deployment with large apps?
Ideally you want to be as stateless as you can, and stay away from session. Perhaps you can use a cookie for tracking the current user via forms auth for example. But you must stay away from in-proc by using distributed cache/session provider so users won't lose session state on app pool recycles.
I think the best is to deploy a new site for new sessions, and mantain existing sessions in the old one.
I feel that "The blue green deployment strategy" article linked below can be hacked with a few changes to do that (Disallow New Connections instead of issue a "drain", using sticky sessions).
https://kevinareed.com/2015/11/07/how-to-deploy-anything-in-iis-with-zero-downtime-on-a-single-server/
I'm currently designing a new website built on MVC and I wonder what is the right way to manage state.
The state should contain the userId and some structs of the user info, and should be kept during the whole session of the user while he's logged in (across http requests)
The important criteria:
1) Support scalability
2) Performance
The easy way is to use the Session object, but it doesn't support scalability. If different requests during the session go through different IIS servers, the session won't be kept. Although I've heard of load balancing tools which route all requests of a single session through the same machine, I'm not sure that it's a good practice to rely on it (isn't it?)
Another option that I've read about, is keeping the state data in special state servers which are running a RAM DB (like Cassandra for Linux or Redis for Windows). But it seems to me an overkill at this stage of the development.
Do you have any other suggestions?
I would like to start with something simple at the moment, but keep the design ready for a more advanced solution at the future.
Any best practice or code/design suggestions will be appreciated.
Thanks,
Edi.
(1) Use Sql Server to Store Session State
(2) Use Memcached as a Session State Provider
(3) Cook up your own solution using Caching on an external caching provider: look into using something like the ServiceStack Caching Framework. Using this, you can use Redis, Memcached, Azure or AWS to handle caching.
Next, create a KeyFactory to handle generation of keys for specific items. The item keys would include the UserId (which you would always have from FormsAuthentication UserId (assuming that you are using FormsAuthentication). Then store any Session data for the user in the cache. Using this approach you are using Caching in place of Session, and the cache can be shared across multiple servers.
Note: you can have different approaches regarding clearing out the user's data whenever they begin a new session. Potential approaches include:
Include the user's session start dateTime in the cacheKey, and auto-expire entries when they are no longer fresh
Clear out all potential entries for a user when they begin a new session
If you are using .NET 4.5 and dependent on the type and amount of information you are keeping on users you may want to look at using claims to store information about the user. In .NET 4.5 all Principals inherit from ClaimsPrincipal. ClaimsPrincipal already uses claims to store the user name, roles and other information. You can create your own service to transform claims, which will allow you to add additional information to the Principal user.
I have a few classes that are instantiated using ninject "Session Scoping" - because these objects get passed between controller methods and then only get persisted once, this technique worked well for this project.
With Azure's multi-hosting capabilities I assume that InSessionScope is no longer reliable because any of the servers could be servicing my request.
Does anyone know if I am wrong and can still use Session Scoping with Azure or does anyone know of an alternative to this?
In this case you would use a custom session state provider that works with Windows Azure:
Session State Provider for Windows Azure Caching
Azure Providers
Now if you use a session state provider other than InProc, you'll need to make sure that whatever you store in session is serializable. You should test this since this might have an impact on how your application works today.
So despite the warnings, I think I need to build a custom STS. We will support an arbitrary number of customers who provide identity information via SAML.
What is the best practice to store details on each IP? Most examples seem to store this info in the STS's web.config. That seems like it wouldn't scale real well.
Is there an obvious reason not to just store this stuff in a db and load it when the requests come in?
Fundamentally, if the Identity Providers will change over time, such as via some online administration function, rather than a new application deployment, it makes total sense to store the information in a database (or other Storage).
I think this is a potential issue for any multi-tenanted service that is federating identity with the customer.
ADFS v2.0 (which is Microsoft's STS product) stores its details in either a SQL Server DB (or SQL Server DB farm) or a Windows Internal DB. So if it's good enough for Microsoft ...
I notice in the azure examples they are using:
<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
Can someone explain what this is used for with MVC3? I'm very confused about session state. Do I really need to use it if my application does not have anything like a shopping cart? Is it needed if I just want to do simple authentication? I removed the code from my web.config and my authentication still seems to work.
If you're publishing your application to Azure and you're using Session in any way (this includes MVC's TempData) then you will probably need to use some kind of central storage for session, rather than using the default "InProc" provider which just stores the user's session in the application's own memory. With azure, you can use, among others, SQL Azure or the AppFabric Cache (still in CTP).
Here is a good lab for AppFabric:
http://msdn.microsoft.com/en-us/gg457897
And here's one for SQL Azure (not supported): http://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx
This is because you could have mutiple instances running or you instance could be moved at any given moment.
It sounds like your application doesn't currently use Session State so you won't need to worry about it. (although, remember that the TempData dictionary uses Session under the hood)