ASP .NET 会话状态的“InProc”与“StateServer”的最佳实践答案

【问题标题】：Best practices for 'InProc' vs 'StateServer' for ASP .NET session stateASP .NET 会话状态的“InProc”与“StateServer”的最佳实践
【发布时间】：2009-02-18 16:00:23
【问题描述】：

我们有一个 ASP .NET 应用程序在单个 Web 服务器（无场）上运行。目前，我们使用默认的“InProc”会话存储。是否值得考虑改用 ASP .NET 状态服务？如果我们走这条路，我们很可能只是在与应用程序相同的机器上运行服务本身，因此通过网络进行调用以获取和设置会话信息不会成为问题。我们之所以考虑这样做，是为了避免在应用程序池回收时丢失会话数据。

另外，使用 SQL Server 暂时不适用，所以我们只讨论进程内服务器与状态服务器。

在这种情况下，每种模式的优缺点是什么？

【问题讨论】：

标签： asp.net

【解决方案1】：

嗯，状态服务器比 proc 慢一点。您从中获得的好处是，如果您需要回收应用程序池，那么应用程序的状态（用户会话等）将不受影响。如果你将来打算使用状态服务器，我现在就开始使用它。在进程中，对象按原样存储在内存中，但在状态服务器中，它们是序列化的。如果您打算稍后进行切换，这可能是一件大事，因为您必须检查您存储在 state 中的所有内容是否都是可序列化的。如果您从这种限制开始，您就可以预先知道（当您正在积极处理该模块时）什么会起作用，什么不会。

【讨论】：

网络农场可能在我们的未来，所以我同意我们现在不妨采取行动，找出我们可能遇到的任何不可序列化的问题。

【解决方案2】：

我觉得这是YAGNI的经典案例。

InProc 简单有效。除非对单独的状态服务有特定需求，否则您为什么会考虑做出这样的改变？事实上，如果您将站点分布在多台服务器上，唯一真正的优势就出现了——而您没有将您的站点分布在多台服务器上，这很可能是浪费精力。即使您非常确定自己最终会迁移到多台服务器，我也不会进行切换，除非并且直到启动第二台服务器的时候。同样，请阅读 YAGNI 链接上的文章以了解原因。

相反，请利用您将节省的时间来改进您的网站...

有关您的替代方案的更多信息，请访问here...

【讨论】：

我们一直在考虑它是有原因的，我应该在问题中包含这个原因（我现在会更新问题）除非这个原因，我同意这可能是雅格尼。
好的，我明白了。我想知道...为什么应用程序池在生产服务器上回收？这对我们来说非常非常罕见！

【解决方案3】：

无论如何，我都非常喜欢使用 StateService。我们过去只使用 InProc，但事实证明（显然）有各种奇怪的方式可以在您不知道的情况下回收 appPool。

过去，由于某种莫名其妙的回收行为，我们曾经让客户在网络系统中每周一次左右失去他们的会话。一旦我们切换到 StateService，我们就再也没有遇到过这个问题了。

【讨论】：

【解决方案4】：

我喜欢使用 StateService 只是因为如果您确实需要跨多个 servive 分发您的应用程序，那么更改它就少了一件事情。它允许您在不丢失所有会话的情况下回收 IIS。虽然这对于只有一台服务器并没有多大用处，但它看起来很不错。

我的理由更多的是一种普遍的感觉。但我从来没有遇到过问题。

【讨论】：

【解决方案5】：

如果我错了，请纠正我，但从我读到的内容来看，还有另一个优点/缺点：

inproc 强制使用单个工作进程，因此在回收时会丢失会话状态
stateserver 允许使用网络花园（即将应用程序池配置为在例如 4 个工作人员上运行）

【讨论】：