12

我找到了很多比较 InProc、StateServer 和 SQLServer 以进行 ASP.NET 状态管理的重要信息，但我似乎找不到任何性能基准比较。很明显，InProc 比 StateServer 快，而 StateServer 又比 SQLServer 快，但不清楚多快。我意识到它会因应用程序和环境而有很大差异，但是对它们的比较有一个相对的了解是很有价值的。

你知道你可以分享的任何基准测试吗？或者对此有任何个人经验？谢谢！

4

2 回答 2

7

我有个人经验，但没有基准或实际记录的指标可以分享。我们最初创建了一个 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 的不是速度，而是内存使用量。访问速度的好处肯定不会超过首先将数据保存在内存中的需要。

于 2011-05-11T16:52:11.173 回答
6

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

  • ASP.Net 进程内
  • ASP.Net 会话状态服务器
  • ASP.Net Sql 服务器
  • 沙发底座
  • 蒙古数据库
  • 乌鸦数据库
  • Redis（这个，TheCloudlessSky，不是这个AngiesList）

AppHarbor 也推荐 memcached，但没有基准。 http://support.appharbor.com/kb/tips-and-tricks/using-memcached-backed-sessionprovider 并提供 Session Provider https://github.com/friism/Memcached-Providers

于 2014-03-23T20:37:44.483 回答