具有单个 Web 服务器的 InProc 与 AppFabric 会话状态

Question

我有一个 ASP.Net MVC 应用程序，它大量使用会话来保存状态（包括大型数据集合）。目前，它托管在单个 Web 服务器上。会话设置为默认的 InProc。

出现一个问题，即当许多用户在线时，某些用户的应用程序冻结。我猜这是因为 InProc 会话不能很好地扩展，并且进程可用的内存只有这么多。 （如果内存需求超过可用内存会发生什么 - 它会换出到磁盘吗？）

我想到了几个有助于提高可扩展性的解决方案。 (a) Sql server 会话状态； (b) 配置会话状态以使用 AppFabric 缓存。第一个选项看起来是个不错的解决方案，但它会影响性能并要求存储的项目可序列化。

如何在单个 Web 服务器也用作缓存主机的环境中配置会话状态以使用 AppFabric 缓存（又名 Velocity）？这与单服务器环境中的 InProc 有何不同？这会比 InProc 提供更多的可扩展性和可用内存，还是本质上具有相同的限制？

Answer 1

您最好为您的方案实施 AppFabric 缓存。随着系统的增长，您可以为每个新的 Web 节点增加缓存服务器的数量——如果不增加成本，使用 SQL Server 就无法轻松做到这一点。 SQL Server 许可的成本也远高于 AppFabric - 它与 Windows Server 许可捆绑在一起。

SQL Server 将提供的唯一好处是可恢复性，但对于您的需要，这可能是矫枉过正。

见related SO post discussing AppFabric Cache vs. SQL Server for session。

---

至于 AppFabric Cache 与 InProc...

如果您遇到内存限制，您可以将 AppFabric 缓存 放在另一台服务器上。 InProc 无法做到这一点。

以下是 AppFabric 缓存的其他一些其他好处：

1. 支持Local Cache 以加快序列化/反序列化中涉及的检索成本。
2. 针对cache eviction and expiration policies 提供更细粒度的控件。
3. 支持compression of session contents to reduce network bandwidth。
4. Blob mode versus single item retrieval 改进大型对象的数据检索。
5. Same session state store can be used across multiple applications（通过 sharedId）。

Answer 2

最重要的是会话将在应用程序池回收甚至重新部署应用程序后继续存在。

AppFabric 还可以序列化IXmlSerializable 对象以及[Serializable]。如果您尝试使用进程外 ASP.NET 会话服务，那么讽刺的是您无法序列化 IXmlSerializable 对象，例如 XElement。如果需要，您还可以进行完全自定义的序列化。使用 AppFabric，如果您以这种方式移动，您的应用将更加“天蓝色”。

当然，如果您有需要，您可以使用它来缓存其他数据。