I am using an application variables to store the values and again access it.but my Question here as we using multiple servers (web farms). will be there any issue whiling access the values or it not worth to store values in application state variables when we are going ahead with multiple server
Thanks
prince
No, Application State is not shared across the servers in a web farm, as per the documentation (see the section entitled Scalability).
Application state is not shared among multiple servers serving the
same application, as in a Web farm, or among multiple worker processes
serving the same application on the same server, as in a Web garden.
Your application therefore cannot rely on application state containing
the same data for application state across different servers or
processes.
You will need to find some other store for this shared information, i.e. via a database or shared cache.
However, you will be able to share viewstate and forms authenticate tickets across all servers in the web farm, but you must set the <machineKey> to the same values on all servers.
From the first article below:
If you deploy your application in a Web farm, you must ensure that the
configuration files on each server share the same value for
validationKey and decryptionKey, which are used for hashing and
decryption respectively. This is required because you cannot guarantee
which server will handle successive requests.
These MSDN articles have more information:
http://msdn.microsoft.com/en-us/library/ff649308.aspx#paght000007_webfarmdeploymentconsiderations
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
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.
I'm trying to share authentication cookies across a .NET Core app and an MVC 5 application. This is possible according to: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/compatibility/cookie-sharing but requires the servers to have physical access to a shared directory that holds the Data Protection keys.
How does one go about sharing these keys if the servers are not physically located together? In my case they're different Azure Web Sites.
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.
Any advise on this one would be greatly appreciated, I've been researching all morning and I'm still scratching my head. I started at a new company a few weeks ago, where I'm the only .NET developer as the development was originally done by an outsourcing company and I've been asked to research.
My knowledge of the existing system is extremely limited but from what I can gather the situation is as follows.
We would like to enable sticky sessions on an asp.net web site. From my research I have gathered, I need to do the following steps. We are using the ASP.NET State Service
The setup is a load balance server which services two web servers.
Ensure that both web servers have the same machine key.
Ensure that the websites have been precompiled before deployment. For serialisation of objects by ASP.NET State Service.
Ensure that the application path on the iis metabase is identical on both web servers.
I bit of knowledge I'm lacking is where are the sessions are stored. Are the sessions stored on the load balancer, can they be stored on the load balancer? From what I've read they are stored by the ASP.NET State Service, should the service be running on the load balancer therefore the sessions are stored o the load balancer.
From what I understand the ASP.NET state service runs on each of the web servers and they just talk to each other so that the sessions are stored across both servers. I assume that the way they do this is based on the type of algorithm that is used. Any information would be greatly appreciated.
zeencat, take a look at http://msdn.microsoft.com/en-us/library/ms178586.aspx at the State Server Mode section:
StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool.
Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed.
From what I understand the ASP.Net state service runs on one server, as a service called ASP.NET state service, both servers will have the same web.config file:
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=SampleStateServer:42424"
cookieless="false"
timeout="20"/>
</system.web>
</configuration>
This way, the session is stored on the server who hosts the service.
Hope it helps,
[]
Also look at using ElastiCache if you are in AWS or Redis if on premise as your ASP.NET session store instead of using sticky sessions. It has more advantages in terms of auto-scaling, load balancing and I would say performance. More info at http://blogs.msdn.com/b/webdev/archive/2014/05/12/announcing-asp-net-session-state-provider-for-redis-preview-release.aspx
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