ASP.NET 会话状态性能基准
我发现了很多关于 ASP.NET 状态管理的 InProc、StateServer 和 SQLServer 比较的重要信息，但我似乎找不到任何性能基准比较。很明显，InProc 比 StateServer 快，而 StateServer 又比 SQLServer 快，但不清楚快多少。我意识到它会因应用程序和环境的不同而有很大差异，但是对它们如何进行比较有一个相对的了解将是有价值的。
您是否知道可以分享的任何已执行的基准测试？或者有这方面的个人经验吗？谢谢你！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我有个人经验，但没有基准或实际记录的指标可以分享。我们最初创建了一个 Asp.Net 站点，它使用 InProc 方法在会话中存储比平常更大的用户对象。我们发现对象的大小和错误处理库的性质导致了 2 种不良行为。第一个是在进程期间以随机间隔回收应用程序池。因为 w3wp.exe 进程会在中途回收自身，所以它实际上会转储会话并且对象将会丢失。这导致其他代码启动并修复会话，并增加了交易的延迟。我们还发现（尽管这不是一个可怕的问题，而且我只是在尝试调试我刚才描述的内存丢失时才发现）会话中对象的大小以及页面本身的库中加载的一些对象会导致w3wp.exe 反复将其自身调入和调出。对于仅涉及会话对象或这些库对象但不涉及两者的较小请求，进程上没有奇怪的分页行为。
从 InProc 迁移到 StateServer 时，我们发现回收立即得到回报。池实际上最终回收了更少的东西，即使这样做了，我们的会话对象仍然保留在单独的内存中。我们还注意到，这创建了一个通用的“仅限库”条件，如上所述，关于分页，我们没有再次遇到这种情况（尽管不可否认，我在 1 个月的正常运行时间后停止了检查）。当时我们在访问某些框架库时确实遇到了非常小的延迟，但是当我们从 2.0 升级到 3.5 时，这些访问异常完全消失了。我们希望很快从 3.5 升级到 4.0 时也能出现类似的行为。
尝试使用 SQLServer 作为状态控制器的测试站点，我们发现的唯一延迟是初始会话创建/存储。在 SQL 中更新/访问会话的后续调用与 StateServer 选项没有真正的区别。我没有任何指标，但任何系统上都没有任何迹象表明行为存在差异。时间戳在各个方面都有相当的差异。我们确实获得了一个好处，尽管它的使用潜力很少，但我们能够将用户数据库直接与会话状态服务器耦合，并直接比较时间戳、状态和其他专用会话变量。我们并不真正需要此功能，并且 StateServer 选项已经在我们的生产服务器上全面展开，因此决定保持原样。
最后，说服我们将 InProc 转储到 StateServer 的并不是速度而是内存使用情况。访问速度的好处肯定不会超过首先将数据存储在内存中的需要。
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.
DevOps 人员有一个很好的基准。
http://www.slideshare.net/devopsguys/best-performing -aspnet-session-state-providers 比较
AppHarbor 还推荐 memcached，但没有基准测试。
http://support.appharbor.com/kb/tips -and-tricks/using-memcached-backed-sessionprovider
并提供会话提供程序 https://github.com/friism/Memcached-Providers
There's a good benchmarks the DevOps Guys.
http://www.slideshare.net/devopsguys/best-performing-aspnet-session-state-providers comparing
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