ASP.NET会话状态性能基准

Question

我发现了许多比较InProc,StateServer和SQLServer for ASP.NET状态管理的好信息,但我似乎无法找到任何性能基准比较.很明显,InProc比StateServer更快,而StateServer又比SQLServer快,但目前尚不清楚速度有多快.我意识到它会因应用程序和环境而有很大差异,但是对它们的比较有一个相对的想法是有价值的.

您知道可以分享的任何基准吗？或者对此有任何亲身经历？谢谢!

Answer 1

我有个人经验但没有基准或实际记录的指标可供分享.我们最初创建了一个Asp.Net站点,该站点使用InProc方法在会话中存储比平常更大的用户对象.我们发现对象的大小和错误处理库的性质导致了2个不受欢迎的行为.第一个是在流程期间以随机间隔回收应用程序池.因为w3wp.exe进程会在中游自行回收,所以它实际上会转储会话并且对象将丢失.这导致其他代码启动并修复会话,并增加了我们的事务延迟.我们还发现(虽然这不是一个可怕的问题,我只是在尝试调试我刚才描述的内存丢失时发现)会话中对象的大小以及为页面本身加载到库中的一些对象会导致w3wp.exe重复进入和退出页面.对于仅涉及会话对象或这些库对象但不涉及两者的较小请求,进程上没有奇怪的分页行为.

在从InProc迁移到StateServer时,我们发现了回收的立即回报.该池实际上最终回收较少,即使它确实我们的会话对象保持在单独的内存中.我们还注意到,这创建了一个通用的"仅库"条件,如上所述的分页,我们没有再次体验它(尽管我承认在1个月的正常运行时间后停止检查).我们确实在访问某些框架库时遇到了非常小的延迟,但是当我们从2.0升级到3.5时,这些访问异常完全消失了.当我们很快从3.5升级到4.0时,我们希望有类似的行为.

尝试使用SQLServer作为状态控制器的测试站点,我们发现的唯一延迟是初始会话创建/存储.在SQL中更新/访问会话的后续调用与StateServer选项没有实际区别.我没有任何指标,但在任何表明行为不同的系统上都没有任何内容.时间戳在所有方面都有可比较的差异.我们获得的好处虽然具有罕见的使用潜力,但我们能够将我们的用户数据库直接与会话状态服务器耦合,并直接比较时间戳,状态和其他专用会话变量.我们并不真正需要这个功能,而且StateServer选项已经在我们的生产服务器上全面展开,所以决定保持原样.

最后,它的速度并不像内存使用那么说服我们为StateServer转储InProc.访问速度的好处绝对不会超过首先将数据存储在内存中的需要.

Answer 2

DevOps Guys有一个很好的基准测试. http://www.slideshare.net/devopsguys/best-performing-aspnet-session-state-providers比较

• ASP.Net In-Proc
• ASP.Net会话状态服务器
• ASP.Net Sql Server
• CouchBase
• MongoDB的
• RavenDb
• Redis(这一个,TheCloudlessSky,不是这个AngiesList)

AppHarbor还建议使用memcached,但没有基准. http://support.appharbor.com/kb/tips-and-tricks/using-memcached-backed-sessionprovider 并提供会话提供程序https://github.com/friism/Memcached-Providers