I read that when using Session objects in an ASP.NET web app hosted in Azure, if the request is handled by a different (virtual) machine, the app cannot see Session variables of another virtual machine (obviously), so it is recommended to use Azure Caching Service.
Just to understand:
can these 'virtual machine switches' happen in 'normal' web sites too?
I mean: if I don't configure redundancy (i.e. multiple instances) do I have the risk to 'not see' session variables just the same?
Thanks in advance.
AB
If you are using Azure Web Sites with a single instance, then you can technically use in-process session storage since all requests are handled by the same instance. Even when using multiple instances in Azure Web Sites, the default behaviour is to use ARR with "sticky" load-balancing, so that all requests for a particular client are routed to the same instance.
However, there are still times when all in-process session data may be lost. If an instance fails, then the site will be quickly transferred to another instance, and any in-memory (or on-disk) data will be lost. For that reason it is better to use some form of separate, persistent storage such as caching, table storage or a SQL database for your session data if it is in any way essential. I believe all the ASP.NET session providers maintain an in-process cache of the underlying store for performance reasons anyway.
If you are using a Cloud Service to run your site, then all requests are load-balanced between all available instances, so separate session storage is essential.
Related
Azure website clarity regarding the instances, are these instances running on multiple machine like a web server farm environment where one client request (session) can be server by different server in the farm.
Issue with server farm asp.net application is that we can loose session variable if that is the case, for this issue to get around we add machine key in web.config that assure client session will always be server by same server so there wont be any lose of session variable.
How does Azure instance work. doesnt it mean we can have 10 websites under same plan let ex s1 Standard.
I am hosting asp.net webform based website on Azure I am confused how exactly instance work. there are lot of article on internet to create confusion.
The thing with PaaS is that you don't have to care about that. If you have a statefull site, you can use the ARR Affinity setting to ensure a client gets always to the same instance:
Adding to Martin Brandl's answer.
An App Service Plan can have multiple instances. These instances run all of the apps in that plan. So it is pretty much like a classic web farm. Except it is way easier to manage.
There is a better way of keeping session information in a web farm rather than relying on sticky sessions with ARR Affinity. Put the session data in a central place. For that you can use Azure Redis Cache or SQL Database. There are ready-made session state providers for these that you can just plug in to an ASP.NET application. That way your session state is not stored on the instances, so you don't need to care if clients hit the same server.
The problem I have with ARR Affinity, is that Azure does not guarantee your instances will remain running. A hardware failure could bring one down and you lose a part of your session data. If you use auto-scale, same thing.
With ASP.NET Forms Authentication, its possible to setup all the servers in a webfarm to share the same machine key for encryption of authentication tickets, meaning if you can get by without requiring session state in your application scale out to a web farm is easy.
i.e., http://www.iambacon.co.uk/blog/getting-asp-net-authentication-to-work-on-a-web-farm
Is there a method to do accomplish this disconnected setup using ServiceStack Authentication, or does implementation require a shared session state to be persisted somewhere accessible by all web servers? I'm assuming shared state is required, but if there's a way around it, would interested to learn more... (we load-balance globally, so shared state is a bit more of a challenge)
ServiceStack Sessions are essentially the User Session DTO's serialized in the registered Caching providers. All Caching providers except for MemoryCacheClient persists to a distributed data store so they're naturally load balanced by just using the same configuration.
The Auth Providers that implement IAuthWithRequest can authenticate on-the-fly and access protected services without prior authentication, namely:
BasicAuthProvider
DigestAuthProvider
AspNetWindowsAuthProvider
But overall this would be worse performance since it has to authenticate on each request instead of a single cache hit to access the users session.
I want to know in which situation i am use this mode ?
Sql Server Mode is one way to handle sessions inside of a web farm for example. If you were to use in proc session state inside of a web farm, you would not be able to share a session over many boxes. Using Sql Server for the storage of the session means that you can load balance your users over the servers inside of the web farm and the session can be retrieved externally, inside of SQL Server. So one web server would allow you to use in proc session state. With many servers you need to store the session state in a common place so all web servers can see the same one.
It's mainly used when you want to use your app on a web farm, web garden, or cluster. Since page requests can come from multiple processes or computers, you can't use an in-process session state provider.
http://idunno.org/articles/277.aspx
Greetings,
What do I have to consider when you are coding an ASP .Net website in regards to if the application will run in a environment where there is a load balancer for the IIS?
All user sessions are running by them self with no shared data between sessions. Single connections to MSSQL. Images and files for download will be hosted on one single server.
Windows Server 2008's, C# and .Net 4.0.
The most obvious item is session state. If you are load balancing, multiple requests from the same user may move between servers. The default session provider for ASP.NET (in-proc) doesn't support this (the user would get a new session each time they moved). The easiest solutions are to move to a ASP.NET state server or SQL Server sessions.
FYI: Both of these solutions require that everything that you put into Session be [Serializable]. The in-proc provider doesn't have this requirement, so you may see some runtime errors and need to modify your code when you change providers.
You're going to need to move your session state into the session state service. Avoid keeping objects in session...if you must keep an object in session, make sure it's marked with the Serializable attribute (this is how it is stored, by serialization).
In general, avoid using Sessions. Keep in mind that ASP.Net Session != FormAuthentication. Chances are that your database will be a bottleneck long before the web server, depending on the nature of the application.
Is there a way to share session among asp.net balanced applicatiosn without saving session in DB (i.e. without using SQLServer sessionState)? Actually, could load balancers take care of that by themselves?
To share a user session, yes. You have two options:
User an ASP.NET state server and have the web servers point to that.
Enable sticky sessions on the load balancer, so that once a session is started on a particular machine, all further requests for that session will go to the same machine. (really this is the less ideal of the two as it can still have problems if the app pool resets etc.)
There are other applications from MS etc, that you can use to store state also.