我们在单个Web服务器上运行一个ASP .NET应用程序（没有服务器场）。目前，我们正在使用默认的“InProc”会话存储。是否值得考虑使用ASP .NET状态服务？如果我们走这条路线，我们可能只是在与应用程序相同的机器上运行服务，因此通过网络拨打电话来获取和设置会话信息不会成为问题。我们考虑这个问题的原因是为了避免在应用程序池回收时避免会话数据丢失。
此外，目前暂时使用SQL Server，所以我们只讨论进程内与状态服务器。
此方案中每种模式的优缺点是什么？
答案 0 :(得分：10)
状态服务器比proc更慢一点。您将从中获得的好处是，如果您需要回收应用程序池，那么应用程序的状态（用户会话等）将不受影响。如果您计划将来使用状态服务器，我现在就开始使用它。在进程中，对象按原样存储在内存中，但是对于状态服务器，它们被序列化。如果您打算稍后进行切换，这将是一件大事，因为您必须检查您在状态中存储的所有内容是否可序列化。如果你从这种约束开始，你就会事先知道（当你正在积极地研究那个模块时）什么是有效的，什么不是。
答案 1 :(得分：3)
我认为这是YAGNI的经典案例。
InProc简单有效。除非特别需要单独的州服务，为什么要考虑做出这样的改变呢？实际上，如果您在多个服务器上分发您的站点，并且不在多个服务器上分发您的站点，那么唯一真正的优势就在于此，这可能会浪费精力。即使您非常确定最终迁移到多个服务器，我也不会进行切换，除非是时候启动第二台服务器。再次阅读YAGNI链接中的文章以了解原因。
相反，请使用您节省的时间来改善您的网站...
有关您的替代方案的更多信息，请访问here ...
答案 2 :(得分：2)
我总是在使用StateService时出售，无论如何。我们以前只使用InProc，但事实证明，在你不知道的情况下，appPool可以（显然）有各种奇怪的方式可以回收。
由于某种无法解释的回收行为，我们曾经让客户在网络系统中每周一次松开会话。一旦我们切换到StateService，我们就没有遇到过这个问题了。
答案 3 :(得分：1)
我喜欢使用StateService，因为如果您需要跨多个服务分发您的应用程序，那么更改一件事就更少了。它允许您回收IIS而不会丢失所有会话。虽然这对于只有一台服务器来说并不是那么有用，但它看起来很不错。
我的理由比其他任何事情都更普遍。但我从来没有遇到过这个问题。
答案 4 :(得分：0)
如果我错了，请纠正我，但从我在那里读到的，还有另一个优点/缺点：