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.
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.
We constantly deploy updates to our application
However each deploy terminates all user sessions.
I want to implement a session system that doesnt have this issue using cookies or similar.
What is the best approach?
There are basically four ways of handling session (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.
You are, most likely, using In Process session (the first one listed) which is causing the session drops during the deployment process.
Moving to any of the others would meet your requirement, but none are instance and they all have upsides and downsides, so you'd need to pick the one that meets your (and your organizations) needs.
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
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.
Ok I'm sure this is pretty obvious. But when you say session state is persisted on the "server" in memory, are we talking about IIS or what? When I think of Server-side session State, I think memory in terms of IIS app pools and such. Am I off base or missing anything here?
http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
the term "server" could mean many things. Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)
I wish MS would have explained what they mean because that's pretty relative.
Specifically this, "store on server"
Storing Data on the Server (in memory)
• Session state
• Application state
• Profile Properties
so "on the server" where in memory and what process/app is handling each of these?
" Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)"
Each site runs in an application pool and each application pool is basically a process on your web server. If your session is configured to be in process, your session objects will be stored in that process' memory
It depends. By default it's in the worker process memory, but it can be on a dedicated state server or in SQL or your own custom provider.
From MSDN:
ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
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.
ASP.NET is just a framework; it's a collection of classes, and they execute code. It's this code that provides you with session state, and it stores the information about your session state in some objects, just like a dictionary or similar.
(When doing In Proc, then you have state server, sql server, and custom, where custom can be anything as long as someone has written some code implementing the right interfaces)