Recently to allow concurrent requests at some level and to increase the performance, we enabled EnableSessionState="Readonly" for one our .aspx page for read only access for session data.
I would like to know enabling this in web farm, will this effect any data loose or any other impact in server or user ?
Current Web Farm Settings:
Lets say We have 4 servers.
1. Lets say User A, requests for the page http://example.com/StudentDetails.aspx, this request hits Load Balancer.
2. Load Balancer based on traffic transfer the request to any 1 from 4 avialable servers.
3. Each server Has InProc Session State mode enabled.
4. We ensure that the same server handles subsequent requests from the same client.
Any help would be great.
What impact have you anticipated?
You simply set it read only in one single page. If, as you mentioned, you aren't even sharing sessions between your servers, then effectively for session purposes you don't even have a farm. You just have 4 individual servers. There's no impact on the farm because there's no session sharing.
If you do start sharing sessions as I suggested in the comments, then I still think the impact will be minimal if any at all. Read-only access should lead to less blocking (e.g. as might occur if the user is requesting two session-enabled pages concurrently) but that's all.
Related
Is there a way of limiting the number of asp.net (in-process) sessions from within IIS7? I am thinking along the lines of the existing setting that allows this for classic asp. Basically we want to be able to limit the number of concurrent sessions on a server and once reached redirect other traffic to a "we are busy" type page. On previous systems (classic asp) we have done this by redirecting the 503 response to a holding page.
I realise this could potentially be done from within the asp.net code but monitoring the session start & ends isn't ideal. Is there an extension for IIS that could limit the sessions, or maybe one that is flexible that can use any Perfmon counter?
Many thanks.
There isn't a way to do this out of the box by configuring any Session State configuration settings.
You could write your own provider to do this:
Implementing a Session-State Store Provider
Sample Session-State Store Provider
The example uses SQL but you could modify to create your own in-memory store.
Limiting sessions at the Session State provider level may not be the best way to tackle this problem. The problem you're going to encounter is when you have the scenario where your site has maxed out the number of available sessions but then you have a drop in visitors. Because there is a session state timeout there will be unused session state instances and until these sessions time out you can't accept any more visitors. If your timeout is set to the default (20 minutes) and 20 or 30 users "go away" then it'll be 20 minutes before you can accept new sessions.
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.
Right now, my site is served by a single server, but I anticipate the need to increase my server capacity, soon. Instead of splitting my websites up among multiple servers and having to manage sessions across servers, I want to have multiple web servers all with the same code base on them and use router based round robin load sharing to distribute users to each server. And once a user hits a web server, have him stay with that web server throughout his/her whole session. To my knowledge, I don't need to have any special asp.net code to facilitate this.
Does anyone have any caveats or comments for this approach?
What you are talking about is called sticky sessions or session affinity. If your router supports this, then you are golden.
The only caviat is that the load balancing won't be perfect. If you have a few high-load users who all end up randomly on the same server, they will staty there until the sessions end.
I have implemented this kind of load balancing where I work, and it requires no special asp.net code to implement.
Most (perhap all) load balancers do have the ability to enforce "sticky" sessions where users on the same IP are directed to the same web server on every request. There is no code change required to accomplish this. There are two caveats that come to mind:
Using sticky sessions will mean that the traffic load will not be distributed as evenly as it would if you were not using sticky sessions. However, the distributionshould be"even enough" IMO.
There will be a very small percentage of users using proxy servers that may come in on different IPs on different requests. These users may experience "odd" behavior as they get passed to different servers.
Another characteristic of this configuration is that if one your servers go down the sessions of the users on that server will lose their session as well. I think this is one of the most commonly used setup since it does not require any development effort if the router supports sticky session or session affinity.
As others have mentioned, you should be able to turn on Sticky Sessions on your load balancer, that should take care of most of the "stay on one server" issues for you.
However you will want to ensure you have put settings in place to cope with a user landing on the wrong server mid session - Sticky Sessions are usually based on IP address, and users IPs can change mid session if you're unlucky, or a server may go offline, and the user will be directed to the other server.
You should make sure that your MachineKeys are the same across all servers - this will ensure that you can decrypt the viewstate correctly on all servers.
If you own the servers, you can do this in the machine.config, otherwise you can set it at the application level in the web.config, more details can be found in this how to:
Configure MachineKey in ASP.NET 2.0
There are some slight differences if you're running on IIS 7.5 - Tess Ferrandez has more details in a recent post "Forms authentication fails after installing IIS 7.5".
The other thing you'll probably want to do is move your sessionState from InProc to either Sql or StateServer.
What should I do If I want to maintain session between HTTP and HTTPS.. In my site's public area some pages are HTTP and some are HTTPS but I want to keep common session for both..
Once your user's have authenticated they will continue to have the same session cookie until it expires whether they are accessing pages with HTTP or HTTPS. Make sure that you are using encryption on your session cookie to make it more difficult to crack if you are passing it over an insecure protocol. You might want to look at the wikipedia article on session hijacking for more information.
There are a number of session state modes in ASP.NET you can use (which can be configured in web.config) apart from the default "In Proc":
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.
See ASP.NET Session-State Modes on MSDN. I haven't tested this for HTTPS, but hopefully StateServer or SQLServer should facilitate this.
One session is maintained per application per user. So if you have one application which has some pages served over https and some over http, you do not have to worry about a new session being created when moving from https to http and vice-versa.
We have 5 balanced web servers with various websites.
What I am trying to achieve is to ensure a single login.
i.e. the same user account cannot login to the same website more than once at any given time.
The method i'm considering for solving this, is to share session amongst the servers so I can control which session is assigned to which account. I can then have control over my logins. If a user logs in and there is already a session assigned to their user account, I can just expire the first session or reject the login.
I don't want to lose the benefit of the balanced servers, so using a single Sql Server as my session state server, or a single server to handle login is not an option.
Is distributed session (something like Scaleout Sofware) the correct approach to achieve this?
Or is there another mechanism to handle single login that i'm blissfully unaware of?
You have two set of problems here:
1) Allowing just one connected user in a web farm scenario
2) Detecting user logoff
To solve the first the only solution is a central storage for some kind of user state, using a central server to store the ASP.Net session or some other kind of centralized user state. This central storage can be SQL Server using the native management of session state (btw also Oracle, from Oracle 11, can support session storage), the AspState service or an external solution, like ScaleOut (as you said) or its open source alternative memcached (see https://sourceforge.net/projects/memcacheddotnet/). Or you can design a simple centralized web service that check active logins against a SQL Server database, this way you can also quickly create reporting tools about logged on users and so on.
Real problem, in my opinion, lies in the second part, that you need to maintain the different "wrong logoff" scenarios that are available in a web world (like closing the browser due to a crash or shutting down applications without logging off), giving you application some way to gracefully work with user that has an old session enabled (as you said simply expiring the first session can work).
Keep also in mind that using a state server like SQL server will not make you loose the balanced servers, if's the way of working to have a web farm environmet and sharing session, only problem lies in performance (if session state become large) and the cost involved in using SQL Server if you do not already have the proper license.