ASP.NET Session State Performance Benchmarks

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!

回答1:

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

回答2:

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.