I'm considering moving our web app session storage from In Proc to State Server. Can anybody give any figures as to the performance difference?
I can't give you performance metrics but it won't be as fast as InProc session state due to certain overheads:
Cross Process calls add overheads
Objects have to be serialised and deserialised
Some objects can't be serialised (XmlDocument for example or those that inherit from MarshalByRef)
That said your session state data will survive application pool and IIS resets which may be the reason you're considering changing.
Related
We're currently building an application in which we rely heavily in storing data in sessions for each individual user. We cannot use Cache since these data are specific to users, and re-querying data when we need it is an expensive process: so the solution was to query once from the DB, store into session, and then keep using it until the session ends. A concern I have is how IIS handles these sessions when too much session data is stored in memory.
when does it know when to clear session data?
how does it determine which session variable to clear out first if memory runs low?
Is there a way to set priories to individual session objects: clear less prioritized data first.
What you're doing is using InProc sessions whereby the sessions are stored in the memory of the current worker process.
when does it know when to clear session data?
InProc sessions are cleared as you might expect when zero requests have been made for the session for the length of the configured session timeout.
<sessionState mode="InProc" timeout="30"/>
However this is not an exact duration. The session will be cleared after the timeout but only when a cleanup is triggered by the internal mechanics of the session handler. Each session doesn't have it's own timer polling for a session timeout. It will get done, when it's optimal for it to be done.
You should also note that since worker processes are regularly recycled any and all sessions stored in that process will be deleted. InProc sessions will also not work in web farms since each request could be handled by a different machine.
how does it determine which session variable to clear out first if memory runs low?
It doesn't. It will simply shift to using virtual memory like any other windows process and as such you would now be backing your sessions with disk based virtual memory instead of chip based memory. Eventually the whole process would get recycled and everything would be wiped as per 1.
Is there a way to set priories to individual session objects: clear less prioritized data first
Not out of the box with InProc. Ultimately the session is just storing objects so you could run your own cleanup according to whatever makes sense for your app by simply tagging your InProc objects with some kind of value. But you'll quickly end up simply replicating the features already available and probably not doing it as well as MS.
Check out System.Web.SessionState namespace for some options but bear in mind that by using InProc you are always going to be held to ransom by worker process recycling which can be triggered by many different things: antivirus software resetting the timestamps on web.config files for example.
For a viable and popular alternative to InProc sessions, check out Redis.
In ASP.NET, sessions enable us to store and retrieve values for a user as the user navigates ASP.NET pages in a web application. However, using too much sessions is discouraged. Why? What are the disadvantages of using too many sessions?
Thanks for those who will answer.
Memory and/or performance
If you store session state in-process (the default), all of your session data are stored in the app pool's local memory. If you have thousands of users you can see why this may be a problem. The problem gets worse when developers don't remove session variables after they're no longer needed (this is very common due to the fact that it's very hard to control the order in which web pages are accessed) and/or when users do not explicitly logout (e.g. by closing the browser window), which leaves all this memory still allocated but no longer used.
If you store session state out of process (e.g. in SQL Server or a separate state server), all of the session variables end up crossing the wire. As you add more variables, more and more data have to get pulled over. This can end up degrading performance.
Concurrency
If a web application uses session state, the data in which the session state is accessed has to be protected from race conditions and other multithreading concerns. As a result, ASP.NET automatically serializes any requests that use session. If you send two requests at the same time, ASP won't even start on the second request until the first one is finished. This can cause unexpected and poor performance on applications that use a lot of AJAX or other logic that is supposed to be asynchronous.
Infrastructure
If you're using local memory for session state, and your web app is load balanced, the load balancer must enforce session stickiness, either with IP address or a cookie. This constrains the load balancer in the way it can handle requests-- all requests for a certain session always hit the same server-- which reduces overall performance and eliminates redundancy.
Loss of data
If the app pool recycles, all sessions running on that app pool lose session state, often requiring users to log out and start over.
Poor code design
Session variables are essentially global variables. Overuse of global variables tends to lead to sloppy code structure. Variables should always be scoped as tightly as possible.
Basically, it consumes server memory. As generally sessions are stored in process, this solution doesn't scale well, as can't be shared between two or more state servers.
We have an MVC web app that uses FormsAuthentication and also stores a couple of variables in Session variables. We've encountered a few situations lately where the session variables are lost, but the user is still logged in. A quick Google lead me to a few SO articles mentioning that In Proc Session State is regularly lost and that if we require it to persist, we should consider moving to a non In Proc solution.
Coming from a classic ASP background, where we relied on Session state for the lifetime of the session, it seems a bit baffling that I now can't rely on it at all. Surely In Proc Session State is of no value to anyone if it can be lost at the drop of a hat? Am I missing something?
I realise that storing it in an SQL server has it's benefits, but for small webapps with little traffic, In Proc is an ideal solution, could it be relied upon.
ASP.NET session state is able to run in a separate process from the ASP.NET host process. If session state is in a separate process, the ASP.NET process can come and go while the session state process remains available. Of course, you can still use session state in process similar to classic ASP, too.
You don’t have to use SQL server to store session data in out of process, you can use out of process state server which can be in memory on the same server as the web server.
You can read more about how to configure out of process session state under http://msdn.microsoft.com/en-us/library/ms972429.aspx
As far as i know in-proc sessions state is lost after recompiling application and recycling application pool. App pool could be recycled if there is not enough memory or it's have regular restart time interval.
I have found a lot of great information comparing InProc, StateServer, and SQLServer for ASP.NET state management, but I can't seem find any performance benchmark comparisons. It is clear that InProc is faster than StateServer which in turn is faster than SQLServer, but it isn't clear how much faster. I realize that it's going to vary greatly by application and environment, but having a relative idea of how they compare would be valuable.
Do you know of any benchmarks that have been performed that you could share? or have any personal experience with this? Thank you!
I have personal experience but no benchmarks or actual recorded metrics to share. We initially created an Asp.Net site which stored a larger than usual user object in session using the InProc method. We found that the size of the object and the nature of our error handling libraries caused 2 undesired behaviors. The first was a recycling of the application pool at random intervals during processes. Because the w3wp.exe process would recycle itself midstream, it would essentially dump the session and the object would be lost. This caused other code to kick in and repair the session, and it increased the latency of our transactions. We also found (although it was not a terrible problem and I only discovered while attempting to debug the memory loss I just described) that the size of the object in session along with some of the objects being loaded in libraries for the page itself would cause the w3wp.exe to page itself in and out repeatedly. For smaller requests that only involved either the session object or these library objects but not both, there was no odd paging behavior on the process.
In moving from InProc to StateServer, we discovered an immediate return on the recycling. The pool actually ended up recycling less, and even when it did our session objects stayed in separate memory. We also noticed that this created a universal "library only" condition as described above with respect to paging and we did not experience it again (though admittedly I stopped checking after 1 month of uptime). We did pick up a very small latency in accessing certain framework libraries at the time, but when we upgraded from 2.0 to 3.5, these access anomalies disappeared entirely. We're hoping for similar behavior when we upgrade from 3.5 to 4.0 soon.
A test site using SQLServer as a state controller was attempted, and the only latency we found was the initial session creation/storage. Subsequent calls to update/access the session in SQL provided no real difference from the StateServer option. I don't have any metrics, but there was nothing on any of the systems that indicated a difference in behavior. Timestamps had comparable differences in all aspects. A benefit we did gain, though it was of rare usage potential, was that we were able to couple our user database directly with the session state server and compare timestamps, statuses, and other specialized session variables directly. We had no real need for this feature, and the StateServer option was already in full swing on our production servers, so a determination to leave it as it was.
In the end, it wasn't speed so much as memory usage that persuaded us to dump InProc for StateServer. The benefits of access speed definitely did not outweigh the need to have the data in memory in the first place.
There's a good benchmarks the DevOps Guys.
http://www.slideshare.net/devopsguys/best-performing-aspnet-session-state-providers comparing
ASP.Net In-Proc
ASP.Net Session State Server
ASP.Net Sql Server
CouchBase
MongoDb
RavenDb
Redis (this one, TheCloudlessSky, not this one AngiesList)
AppHarbor also recommends memcached, but doesn't have a benchmark.
http://support.appharbor.com/kb/tips-and-tricks/using-memcached-backed-sessionprovider
and provides a Session Provider https://github.com/friism/Memcached-Providers
Which session mode in the following ,should i implement for my ASP.Net website?
1)InProc .
2)State Server.
3)SQL Server.
4)Custom.
It depends entirely on your circumstances and the type of website you wish to operate.
I suspect your expected volumes of traffic and the hardware it is running on is also a large factor.
Can you give us more information.
Performance considerations
InProc - Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.
StateServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc. However, the cost of serialization/deserialization can affect performance if you're storing lots
of objects. You have to do performance testing for your own scenario.
SQLServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 25% slower than InProc. Same warning about serialization as in StateServer.
Robustness
InProc - Session state will be lost if the worker process (aspnet_wp.exe) recycles, or if the appdomain restarts. It's because session state is stored in the memory space of an appdomain. For details, see KB324772.
StateServer - Solve the session state loss problem in InProc mode. Allows a webfarm to store session on a central server. Single point of failure at the State Server.
SQLServer - Similar to StateServer. Moreover, session state data can survive a SQL server restart, and you can also take advantage of SQL server failover cluster, after you've followed instructions in KB 311029.
The above is an extract from an article by Peter A. Bromberg available here
There's no one clear answer. It depends on how your app works, how many servers you have, what your tolerance for failure is etc. I would read up on the differences and then make an informed choice.
Providing you make everything that you are storing in the session serializable from the beginning, it is usually fairly easy to switch from one mode to another, unless you are using things like the Session_End event, which only fires when using in proc mode.
The default is InProc, and that works fine for most small and moderate size web sites. You just use it, you don't have to implement anything at all.
If you have any special curcomstances, like load balanced servers or extreme amounts of users, you would need some of the other methods.