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

Question

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

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

我有几个解决方案可以帮助实现可扩展性。 （a）Sql server会话状态; （b）配置会话状态以使用AppFabric缓存。第一个选项看起来是一个很好的解决方案，除了它会影响性能并要求存储的项目可序列化。

如果在单个Web服务器也用作缓存主机的环境中配置会话状态以使用AppFabric缓存（也称为Velocity）怎么样？在单一服务器环境中，这与InProc有何不同？这会提供比InProc更多的可扩展性和可用内存，还是基本上会达到相同的约束条件？

Answer 1

您最好为您的方案实施 AppFabric Cache 。随着系统的增长，您可以使用每个新的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 Cache 放在另一台服务器上。你不能用 InProc 来做到这一点。

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

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（ via sharedId ）。

Answer 2

最重要的是会话将在app-pool循环中存活，甚至可以重新部署应用程序。

AppFabric也可以序列化IXmlSerializable个对象以及[Serializable]。如果您尝试使用out-of-proc ASP.NET会话服务，则具有讽刺意味的是无法序列化IXmlSerializable对象，例如XElement。如果需要，您还可以执行完全自定义的序列化。使用AppFabric，如果您采用这种方式，您的应用就会更加“天蓝色”。

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