ASP.NET session 状态性能基准

Question

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

您是否知道可以分享的任何已执行的基准测试？或者有这方面的个人经验吗？谢谢!

Answer 1

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

从 InProc 迁移到 StateServer 时，我们发现回收立即得到返回。池实际上最终回收了更少的东西，即使这样做了，我们的 session 对象仍然保留在单独的内存中。我们还注意到，这创建了一个通用的“仅限库”条件，如上所述，关于分页，我们没有再次遇到这种情况(尽管不可否认，我在 1 个月的正常运行时间后停止了检查)。当时我们在访问某些框架库时确实遇到了非常小的延迟，但是当我们从 2.0 升级到 3.5 时，这些访问异常完全消失了。我们希望很快从 3.5 升级到 4.0 时也能出现类似的行为。

尝试使用 SQLServer 作为状态 Controller 的测试站点，我们发现的唯一延迟是初始 session 创建/存储。在 SQL 中更新/访问 session 的后续调用与 StateServer 选项没有真正的区别。我没有任何指标，但任何系统上都没有任何迹象表明行为存在差异。时间戳在各个方面都有相当的差异。我们确实获得了一个好处，尽管它的使用潜力很少，但我们能够将用户数据库直接与 session 状态服务器耦合，并直接比较时间戳、状态和其他专用 session 变量。我们并不真正需要此功能，并且 StateServer 选项已经在我们的生产服务器上全面展开，因此决定保持原样。

最终，说服我们将 InProc 转储到 StateServer 的并不是速度而是内存使用情况。访问速度的好处绝对不会超过首先将数据存储在内存中的需要。