Our asp.net web application restarts randomly and kicks off users while they are filling a big batch process form.
- the users have to re logging and fill everything afresh
- so keeping in mind that the application/session restarts randomly - which is the most appropriate technology to use for state management - session state (with MS-SQ L server) or asp.net cache ?
You need to configure something other than InProc for your Asp.Net session state provider. What you use depends on how durable the session data needs to be. The session state service is fine but if it does down it will still affect your application like InProc does today. Using a database is the most durable method, although this costs some performance.
You'll have to try and test which one is most appropriate for your needs.
You might also want to figure out why your app is crashing and fix it. I'm assuming its not a scheduled recycle as you said it was random. Recycling is really a Band-Aid for a badly behaving application.
Related
We're running a PaaS ASP.NET application in an Azure App Service with 3 instances and managing session data outproc in a SQL Server database.
The application is live and we've noticed a large amount of session data for some users when following certain paths e.g. some users have session data upwards of 500k (for a simply site visit with no login the average session is around the 750 - 3000 mark which is what I'd expect).
500k sounds excessive but was wondering what is normal in large enterprise applications these days and the cons of holding so much data in session.
My initial thoughts would be,
No affect on Web App CPU (possible decrease in fact) because not constantly doing queries,
No affect on Web App Memory because we running outproc,
Large spikes in DTU on Sql Server session database when garbage collection runs,
Application may be a bit slower because it takes longer to read and write session data between requests,
May not be ideal for users with poor internet connections,
Possible increase in memory leaks if objects aren't scoped correctly.
Does my reasoning make sense or have I missed something?
Any thoughts and advice would be appreciated,
Many thanks.
I totally agree with your reasoning behind using out-proc session management in Azure App instances.Using IN-PROC sessions in the cloud is a strict no. The reason to host to cloud is to have high availability which is done by having a distributed environment.
Understanding from your point, i assume that speed is a concern to you or if matters to most of the web application , To overcome this , you might think of using Azure redis cache.
Here is the article for configuring session management using Azure redis cache:
Refer the documentation here: https://learn.microsoft.com/en-us/azure/redis-cache/cache-aspnet-session-state-provider
I couldn't find anything about this online so I thought I'd ask here. Do any of you have issues with sessions just randomly clearing on a Windows 2008 Server environment? This problem is completely random and very unpredictable. I have no code that clears sessions except on logout, and not quite sure what could be causing it (well, I have ideas...)
My host, who I've been with for many years (and never had a problem with) is telling me that Windows 2003 is better at managing session variables and that I will likely be rid of this session clearing issue if I were to move to a 2003 Server environment. Thing is, I'm already set up and running on IIS 7 with the URL Rewrite module and I'd rather not move or reconfigure URL rewriting. Tech support says the App Pool I am running on is configured properly. My session timeout is set to 60 minutes in Web.config and my host tells me that session timeout is set to 60 minutes for my domain.
I could optionally go with an Azure AppFabric Cache for sessions but I'd rather not pay an extra $50 a month--it's a pretty small and low income site. I'm currently using a SQL Azure database but from what I hear, database sessions are not ideal on SQL Azure.
Thoughts?
Are you modifying any files in the web site?
Changes to the folder or file structure of the web site often triggers an app pool recycling, resetting sessions. The work-around is to use a durable session store like the SQL Server Session State provider.
Most likely answer is your app pool is recycling on you for some reason or another which will dump your in process session every time. Proximate causes can be lots of things, especially if app pools are shared. An easy way to see if your app pool is getting dumped is to take advantage of asp.net heartbeat monitoring, it could be configured to email you when these events occur.
I'm running several ASP.NET web sites with InProc session state and I would like to retrieve the number of active sessions per web site and hopefully any details around each session (eg client connection details).
My end goal is to be able to see who is connected to the web site so that I can notify them when deploying an update.
Is there any way to do this in .NET without resorting to SQL session state? I looked at Microsoft.Web.Administration but couldn't find a way to do it. And the "Sessions Active" performance counter in perfmon just gives the total sessions for the whole server (as well as not giving any metadata about the sessions).
EDIT: In my tests with performance counters I tested with total Sessions Active when I should have tested with the instance of Sessions Active for my web site. This gets me a little closer but I'd still like to actually retrieve the session information for the web site if possible.
Session is a concept, not an actuality. You can use the asp.net global.asax pseudo events for session start/end to track this concept but it will still only be an approximation. I think your best bet is to flip on your "maintenance in progress" flag and put something in the request pipeline that handles it for all incoming requests.
Not sure how/what you would do with this but I think you're going to be rolling some custom code here.
I have two different web applications: Phase I and Phase II.
Phase II has a dependancy on phase I for some session values.
I want to run these two applications with sharing session variables.
I don't want to use state server to store session.
I have used inproc session and I want to share this session together.
How do I achieve this?
you cant share the session between 2 apps with in-proc sessions because in-proc session runs within the context of an application. you can share the session only by taking it out of the application's context which is possible only with out-proc session mode.
Take a look into this LINK i guess it might help you setting things up.
I was hoping someone could validate my assumptions before I recommend that my client upgrade from a 30/mo to a 80/mo hosting package.
Site: the site is a custom ASP.NET ecommerce site. the shopping carts are stored in the inproc session.
Problem during busy seasons like we are having now, users are frequently losing their shopping carts and their FormsAuthentication Login information.
Solution I wanted to migrate the site to use a SQL Server Session state. My assumptions are that the customers are losing their shopping carts because the InProc sessions are recycling more frequently then their 20 minute timeout, due to load. Will moving the Session to SQL Server or a Session State Server allow customer to store their Shopping Cart Session without the recycle, If so, can once their will I have any issues if I increase the Session timeout to say 40 or 60 minutes
Using the SQL Session state means that sessions should survive a recycle of IIS, (but not a recycle of SQL Server if you use the default script which creates the session database in the tempdb).
There is a script available from the Microsoft website which creates a permanent session state db. I would recommend using that one instead (See here).
So, to basically answer your question. Yes, the SQL Session state will help. You might want to consider also using the out-of-proc state server to test your theory.
Also, as a co-worker has just reminded me, make sure anything you store in the session is marked as serializable before migrating, otherwise you will run into problems.
Could you just add some RAM to the box? That might help and would likely be cheaper and simpler than moving the session to SQL Server. Of course, it would only be a stopgap, but if it saved them $50/mo for a few years it's probably worthwhile.
You might also check the code to see if some other data is left in the session for much longer than necessary.
The assumptions sound reasonable to me. might also want to look at the settings on the AppPool and try to figure out why its recycling. Maybe all you need to do is change those (if you can).