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.
Related
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.
We have a web application through which customers access information. It has been reported by many customers that they are logged out within 5 minutes of no activity. I believe this should only occur after the default 20 minute idle timeout, and this is the case when accessing the web app from inside our domain.
I also spent a few days troubleshooting an error in which some of the user's session data was lost between post backs about 60% of the time, causing an application error since the next page needed the data. The only resolution was a work-around in which I use an additional mechanism for caching the data between postbacks and pull the data from that cache if the session data is gone.
I have also noted that some websites that I visit which require logon credentials will also kick me out between postbacks. For example, a website for a school I take classes at requires logon credentials to their portal. At home I never have any issue, but if I access it from my work domain I often get random errors indicating that my credentials have been lost (i.e. "Unauthorized access is not permitted" after logging in and browsing to a page).
Combing the web for ideas has led me down a few paths, but most address the IIS worker process and ASP.NET and have not helped me.
Does anyone have any ideas or suggestions about how to resolve this?
this is not because of the programming problem...this is because of your host capacity...as you know session are a type of memory that is create for each user when they access to your website and it's terminated when they finish visiting...so in this case I suppose the number of site visitors has risen up,so by default when the memory become full, it kicks one session out and causes all these problems...I think the best thing to do is calling where you get your host services and ask for a service that cover sites needs
You just store your session value in to cookie so you can access that value when session terminate.. or you can use global file to manage session state..
Can anyone list the major differences between session and caching?
Because it seems to me as the same, like sessions are also stored on server and caching. Also, session is used to store the data to reuse, caching too, what exactly could be the major difference that Microsoft created these two components?
A real world scenario would be more helpful.
Sessions are per user session.
Cache is not - it is for everyone.
A session is data cached for one specific user session. When the user logs out or the session expires, that data is gone, and other uses won't tap into that data.
Cache is typically used across user sessions (IE something is cached for all user sessions, not just the current user session).
Session is essentially a special-case of a cache that tracks a 'session' of web requests/responses.
'Cache' is a heavily-used term that generally means 'store something in a faster media' than it normally would be stored in.
Starting on the server there are a variety of ways ASP.NET and IIS can cache for you. On the way to the client you have proxies and CDN's. Then at the browser you have caching rules for the content.
As Raymond Chen says, "A poor cache policy is indistinguishable from a memory leak."
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.
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.