9

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

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

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

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

4

2 回答 2

9

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

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

请参阅有关会话的讨论 AppFabric 缓存与 SQL Server 的相关 SO 帖子。

至于 AppFabric Cache 与 InProc ......

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

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

  1. 支持本地缓存以加快序列化/反序列化所涉及的检索成本。
  2. 提供关于缓存驱逐和过期策略的更细粒度的控制。
  3. 支持会话内容的压缩以减少网络带宽。
  4. Blob 模式与单项检索相比，可改进大型对象的数据检索。
  5. 可以跨多个应用程序使用相同的会话状态存储（通过 sharedId）。
于 2012-07-31T19:22:49.680 回答
0

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

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

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

于 2013-02-23T10:36:25.110 回答