For some reason, the session is abandoning unexpectantly, and wreaking havoc in our application. We've had the app setup to use Session and have been using it for several months with no problems. Now, as we add additional content and store additional info in it, the Session is dumping well before the 20 minute timeout than its supposed to. I'm at a loss for the reason why... could it be because we may be adding a lot of data in the Session (not sure of exact size)? This is my local machine after all (Win 7, using IIS, ASP.NET 4.0, 4 GB RAM).
Or could there be other reasons for this occurrence? Any thoughts?
Thanks.
ASP.Net sessions are stored in the cache. If you are running out of memory then it will be dumped. You need to store the session in a database or other storage to keep it. I'll try to find a relevant link. Sessions are not meant to store tons of data!
Here is a link explaining how to use out-of-process sessions. Basically the idea is that, by default, ASP.Net/IIS will use in-process sessions (which are fastest) but are also limited by the power/storage on the server running IIS. The alternatives are to use a session state farm or a SQL server to store sessions. These are a bit slower but offer more flexibility. You will need to take into account the ability to serialize sessions into your decision.
Here is an excerpt from a book I've been reading (Programming Microsoft ASP.NET 3.5 by Dino Esposito):
Why Does My Session State Sometimes Get Lost?
When the working mode is InProc, the session state is mapped in the memory space of the AppDomain in which the page request is being served. In light of this, the session state is subject to process recycling and AppDomain restarts. As we discussed in Chapter 2, the ASP.NET worker process is periodically restarted to maintain an average good performance; when this happens, the session state is lost. Process recycling depends on the percentage of memory consumption and maybe the number of requests served. Although the process is cyclic, no general consideration can be made regarding the interval of the cycle. Be aware of this when designing your session-based, in-process application. As a general rule, bear in mind that the session state might not be there when you try to access it. Use exception handling or recovery techniques as appropriate for your application.
In Knowledge Base article Q316148, Microsoft suggests that some antivirus software might be marking the web.config or global.asax file as modified, thus causing a new application to be started and subsequently causing the loss of the session state. This holds true also if you or your code modify the timestamp of those files. Also, any addition to or removal from the Bin directory causes the application to restart.
Note: What happens to the session state when a running page hits an error? Will the current dictionary be saved or is it just lost? The state of the session is not saved if, at the end of the request, the page results in an error—that is, the GetLastError method of the Server object returns an exception. However, if in your exception handler you reset the error state by calling Server.ClearError, the values of the session are saved regularly as if no error ever occurred.
I'm assuming you are using Session state in-proc. If this is the case then the most common reason of losing your Session is that the corresponding Application Pool recycles. Go check IIS settings on Application pool and set up Event log entries for such events. You'll find the settings in: "Advanced settings" of your app pool -> "Recycling" -> "Generate Recycle Event Log Entry". Set them all to true and see if it will give you the reason of your Session State loss.
Also if you change data on given sites a lot then it will eventually trigger app pool recycling.
More ideas on app pool recycling:
http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx
Related
I am learning about the State management in ASP.Net using sessions.
I have recently used out of proc ASP.Net session state server for storing my application's session data.
What I wish to know is what happens to a session in the asp.net session state server if it is Abandoned. How is the memory managed on the asp.net session state server's end.
The behavior that I have observed is as follows:
Initially before creating a session in my application I checked, through windows task manager, the memory being consumed by the asp.net session state process. It was around 2300 KB.
Then I created a session in my application, serialized and added a lot of data to it, after which the asp.net session state process memory increased to about 4700 KB.
Now I tried removing, clearing and abandoning(Session.Abandon()) the session but the memory consumed by asp.net session state process did not decrease, it stayed around 4300.
Can you tell me if there is any explicit memory management steps to be followed for out of proc sessions or am I missing any basic steps here.
How is this memory handled by asp.net session state process? If it is not how can I manage it?
Once you don't have any more references (including the Session object) to your data, the garbage collector will clean it up.
This is non-deterministic, so you don't know when that will happen, but it will, eventually.
If it does never happen, then you probably have other references to the data somewhere.
Each time when I stop debugging on localhost and start again, session data gets cleared. So, I have to log- out and log-in again to reach same point. This has become a pain because I have to go through the whole log-in process to reach the page that I was working on.
Any help on this is much appreciated.
If you're using InProc session state management (the default), then you're going to be out of luck. Whenever the IIS worker process restarts (when you start debugging), the session state is cleared. The advantage to InProc, of course, is that it runs in memory, so it's faster.
However, you could switch to using a state server or a database to manage the sessions. Those both run out-of-process, meaning they don't get cleared when IIS restarts, or when you start debugging.
See This Microsoft article for setting up a state server to manage sessions.
See This Microsoft article for setting up a SQL server for managing sessions.
Or perhaps, an alternative could be to use the #if DEBUG directive to hard-code and pre-populate a username and password during the login process? That could at least save typing time :)
I am working on an OLAP application, WCF + Silverlight clients (up to 100 concurrent users). Unfortunately from time to time, a specific service call goes crazy (although it is perfectly valid, just too complex) and occasionally (once a month) brings the whole server down (by consuming all CPU).
A solution would involve killing user request or even the whole user session which is not a big deal for us from the business perspective - recovering/restarting the whole application is.
The idea of isolating user sessions into separate processes is very tempting: CPU/memory throttling and clean resource disposal (not like Thread.Abort) - if modern browsers can do this just for web pages, maybe it's time to do this on servers. We just want to evaluate this concept and see pros and cons in our particular scenario.
Hence the questions:
Is there already an existing library/framework which will be useful for managing processes (like pre-spawning/reusing processes, throttling, kill after timeout)?
Are there any "best practices" or guidelines how to create such architecture?
I was having same problem with my WCF services they too serve more than 100 clients..
and problem which i discovered using IIS logs (C:\Windows\System32\LogFiles\HTTPERR)
I found my problem in Application Pool Recycle timeout on IIS setting.
Application pool was getting restarted every 48 hours and which was causing issues with already subscribed clients.
So i would suggest
1. Analyze the http error logs and IIS logs which will give more information about all the application pools status if any gets shutdown or recycled.
2. If application pool crashes then Setup for Windbg and attach the process set the correct source file path. It will tell you the location if any exceptions are occurring.
In asp.net, the default session time out is 20 minutes. Suppose if i am changing the session time out period to 2 hours or greater than of its, then will it cause any performance issue on server side?
I would like to know Is there any limitations or disadvantages of using maximum session out time in asp.net?
Please guide me to get out of this issue?
Sessions are maintained on server for each user. Increase in session time out will prevent the Server from releasing memory allocated to inactive session.
I would like to know Is there any limitations or disadvantages of
using maximum session out time in asp.net?
HttpSessionState.Timeout Property
The Timeout property cannot be set to a value greater than 525,600
minutes (1 year). The default value is 20 minutes.
Disadvantage:
You will have performance issues if you have large number of users and with increase in session timeout, your inactive sessions will remain in Web server memory which may cause application pool to recycle, which would result in loosing all sessions for all users.
If you are you using IIS6 or greater then depending on your Application Pool settings it may affect how frequently the w3wp process is recycled. When the app pool is recycled your sessions will be lost unless you use out-of-process session state management or sql as a session state host.
If you increase the timeout to two hours individual users wont lose their session as often, but it increases the odds that all users browsing the site will occasionally get logged off when the process is recycled.
Increasing the session time means that a web page left idle is less likely to time out (such as if the user goes to lunch leaving the web page open). However, this takes up more server resources, since, as Habib says, the server must store the user information during this time.
It can also be is a security risk. If the user closes the web page rather than logs out, it increases the window for a CSRF attack.
The best thing to do is understand how your users use the web page. If pages must be kept open for long periods, look at a periodic callback or refresh for the page. Alternatively, if the site is security sensitive, consider logging the user out automatically after a period of inactivity.
Take in consideration that if your trying to raise the timeout value in a shared hosting environment you will fail as they block you from this by set that value in the machine.config file and hat takes precedent, you will need to use SQL Session 's for that and you will be free to change that timeout time as you please.
They also normally restart the AppPool every often to unblock any malicious or bad code that could block other websites, and every time the AppPool restart, here goes all your sessions (not if you use SQL Sessions instead, of course)...
In the other hand, if your hosting the web application yourself, aside of the size in memory (remember that Im assuming that you are saying user sessions and as the name says, are per user, per application you would use Application Sessions). If you consider this memory increase, nothing, not even performance would be diminish.
We recently changed from using InProc to StateServer for storing Session information.
I was wondering, if it's possible to update configuration files on the website now without losing session information. As when we used InProc and updated resource files (like language files), web config files, global.asax or files in the App_Code, we found that sessions appeared to reset and received errors like
'Object reference not set to an instance of an object'
Does this change with going to StateServer? Is it safe to update these types of files without losing the session data? I have run a couple of tests on our test system, and it appears that it works OK, but I'm not 100% confident...
A simple answer to your query is YES
Further more saying...
- Using State Server, session is serialized and stored in memory in a separate process (aspnet_state.exe).
- State Server can run on another machine.
- Session is persistent, you don't need to be afraid that your session data is lost during application restarts
- When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc.
- The cost of serialization/deserialization can affect performance if you're storing lots of objects.
- Solve the session state loss problem in InProc mode. Allows a webfarm to store ASP.NET session on a central server. Single point of failure at the State Server.
For more refer:
- Steps for session inproc mode to state server
Yes it does. Once your session data are out-of-process it's safe to restart worker processes. You can test it by logging in to your site, making some actions that involve session update and killing the corresponding w3wp.exe process (assuming it's IIS 7+) from the task manager (or just touching web.config).