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

好吧,状态服务器比进程内慢一点。这样做的好处是,如果您需要回收应用程序池,那么应用程序的状态(用户会话等)将不受影响。如果您打算将来使用状态服务器,我现在就开始使用它。在进程内,对象按原样存储在内存中,但在状态服务器中,对象被序列化。如果您计划稍后进行切换,这将是一件大事,因为您必须检查存储在状态中的所有内容是否都是可序列化的。如果你从这个约束开始,你就预先知道(当你在积极地研究那个模块的时候)什么能起作用,什么不能起作用。

我认为这是 YAGNI .

Inproc简单有效。除非有单独的州政府服务的特殊需要,你为什么要考虑做出这样的改变?事实上,如果您将站点分布在多个服务器上,那么唯一真正的优势就是 不是 将站点分布在多个服务器上,这很可能是浪费精力。即使你很确定你会 最后 迁移到多个服务器上,我不会进行切换,除非并且直到启动第二个服务器。再次阅读Yagni链接上的文章了解原因。

相反,利用你保存的时间来改进你的网站…

有关您的备选方案的更多信息,请参阅 here …

不管怎样,我总是喜欢使用StateService。我们过去只使用inproc,但事实证明(显然)有各种各样的奇怪的方法,应用程序池可以在不知道的情况下回收。

由于某种无法解释的回收行为,我们曾经让客户每周在网络系统中释放一次会话。一旦我们切换到StateService,我们就不再有那个问题了。

我喜欢使用StateService,因为如果你确实需要将你的应用程序分发到多个服务中,那么改变它就少了一件事。它允许您回收IIS,而不会丢失所有会话。虽然这对于只有一台服务器来说并没有那么有用,但看起来有点不错。

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

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

• 内肛 强制使用单个WorkerProcess,从而在回收时丢失sessionState
• 政治家 允许使用Web花园(例如,将应用程序池配置为运行,例如4个工作人员)