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
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 working on an ASP.net 4 web application using MVC5. I'm curious as to where sessions are stored in the default application scaffold running locally and whether there's any configuration available.
The session is configured on web.config. By default is saved on memory and a service that runs on server is handle that. Other way is to save it on a database...
This is the Session-State Modes... from MSDN:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This 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.
SQLServer mode stores session state in a SQL Server database. This 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.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
I need your help to sort out one problem with session timeout in my application which are hosted on Azure platform.
I have developed web application in asp.net and make login functionality with session and put following code maintain timeout period for session like
<sessionState mode="InProc" timeout="20"></sessionState>
It working fine on local system but when i will tested it with live URL on Azure platform it will signout frequently (session expired).
Can any one please suggest me how can i resolve this issues?
Thanks
Arun.
Are you running more than one WebRole instance? Remember, "InProc" session-state will not be shared across multiple web-role instances. In fact, InProc session state is "evil" in the cloud world, will not work for any deployments with more than 1 instance running. You really want to use another provider, like Session provider for AppFabric Cache
Are you sure the session is expiring? If you are using ASP.NET forms authentication there is another timeout to consider (here I have set it to 180 mins)
<authentication mode="Forms">
<forms loginUrl="Login/" timeout="180"/>
</authentication>
If you do have multiple instances Igorek is right - the session will not be shared.
Please see how-does-microsoft-azure-handle-session-state/1023125#1023125
or refer to the Azure SDK for more information.
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.
I'd like to experiment with the out of process session provider in ASP.NET/IIS7 (non-in memory). I understand that then a different process is taking care of my session state, so that I could restart the application domain/w3wp without losing session information.
However, how do I set this up, preferably pretty much transparent to my web application?
Thank you!
Please see Configuring Out-of-Process Session State with the ASP.NET State Service (IIS 6.0):
If you decide to manage session state
by using the ASP.NET state service,
you must determine whether you are
going to maintain session state for a
Web garden or a Web farm. Then you
need to ensure that the ASP.NET state
service (Aspnet_state.exe) is running
and, that it is configured to start
automatically.