我过去曾听过建议在项目早期使用 SqlServer / StateServer，因此当您进行扩展时，您不会陷入使用不可序列化对象 InProc 的开发人员的陷阱，并且在稍后移动到 SqlServer / StateServer 时它会中断。
目前我们不需要使用 SqlServer 会话状态的 InProc，因为我们刚刚启动，但我们可能需要合理快速地扩展。
在使用 InProc 时，是否有人对强制可序列化对象有任何建议？也许创建一个包装器？
问问题
333 次
1 回答
2
重要的是要记住，使用 SqlServer / StateServer 不仅仅是横向扩展（网络农场）。即使在一台服务器上，您也可能在仅使用 InProc 会话时遇到问题。基本上，在使用 InProc 时，应用程序池回收时“实时”的任何会话都会丢失。把它放在上下文中，你可能正在运行一个购买漏斗，并且在会话中存储了一些对过程至关重要的东西（为什么这可能是不好的做法是另一个对话）。无论如何，如果该会话信息损坏/丢失，则用户将无法继续。因此，应用程序池会回收并丢失任何当前的实时会话 - 因此当前在您的购买渠道中的所有客户都会退出并可能会丢失。
仅出于这个原因，我总是建议至少运行 SqlServer 会话（甚至在本地）。更好的架构通常可以消除任何性能问题。如果您确实遇到性能问题，您可能会查看我应该更快的第 3 方 StateServer 实现。
如果在阅读了在实时服务器上运行 InProc 的缺点之后，您仍然很乐意这样做（这是您的原因，所以这很好）我唯一可以推荐的就是更改您的开发服务器（或测试）以运行使用 SqlState 并让 Live 运行 InProc。这样您就可以在不使用 InProc 的环境中看到任何问题，并且可以在非实时环境中修复它们。然后，如果您决定切换 Live，您就会知道它不需要任何额外的开发工作，一切都应该没问题。
于 2012-05-03T09:13:37.773 回答