25

在我开始使用会话状态服务器以使我的应用程序中的会话状态与 InProc 状态相比更加健壮之前，我想找到一个优缺点列表进行评估。

更新 1：还有关于生存的应用程序池回收吗？

更新 2：会话的寿命和结束时间如何？

4

6 回答 6

32

以下是 Rob Howard 的ASP.NET 会话状态文章中对您的三个选项的优缺点的规范分析：

  • 进行中。进程中的性能最好，因为会话状态内存保存在 ASP.NET 进程中。对于托管在单个服务器上的 Web 应用程序，保证用户被重定向到正确服务器的应用程序，或者当会话状态数据不重要时（从某种意义上说，它可以重新构造或重新填充） ，这是要选择的模式。

  • 进程外。当性能很重要但您不能保证用户将从哪个服务器请求应用程序时，最好使用此模式。使用进程外模式，您可以获得从内存读取的性能以及管理所有服务器状态的单独进程的可靠性。

  • SQL 服务器。当数据的可靠性对应用程序的稳定性至关重要时，最好使用此模式，因为可以对数据库进行集群以应对故障情况。性能不如进程外快，但代价是更高级别的可靠性。

进程外（又名“StateServer”）和 SQL-Server 选项都可以在 Web 应用程序重新启动（包括应用程序池循环）后继续存在，并且都使会话数据可用于集群/场中的多个服务器。

最后，它可能不言而喻，但基本的进程内设置是最容易配置的，这在许多环境中是一个有意义的“专业人士”。

Tim Sneath 的ASP.NET 会话状态：体系结构和性能注意事项添加了一些附加信息，关于会话状态模式的 MSDN 主题是一个可靠的最新资源。

于 2010-04-26T14:41:03.700 回答
6

State Server 是一个很好的（！）入门选择。为什么？因为这意味着您的应用程序现在与任何进程外存储模式兼容。

如果您目前正在开发您的网站，InProc并希望在以后搬入StateServer，SqlServer您可能会遇到序列化问题。并非总是如此，但确实会发生。

一些例子包括（一些已经提到）：

  • Ops 在您不知情的情况下开始计划定期的 IIS 应用程序池回收
  • 内存经常不足
  • 您将在生产环境中使用负载均衡器，并且不能保证同一个网站会收到相同的请求。

因此，最好尽早解决这个问题。它只是一个配置更改和一个服务启动；繁荣！

这也意味着，如果您决定采用完全不同的会话存储路线，例如使用 Redis（分布式键/值存储）或 RavenDB（文档数据库），那么您已经排序。

这确实是对 1 分钟工作的良好投资。您现在已准备好使用 Web 场、负载平衡器和您决定对其进行原型设计的任何其他会话管理系统。

于 2014-07-11T08:05:12.603 回答
5

我想说使用In_Proc的一大缺点是，如果应用程序池或域被回收，会话状态可能会丢失。这可能随时发生，例如，如果服务器内存不足等。我个人从不依赖In_Proc会话来处理您不想丢失的任何内容。我花了几个小时调试有零星问题的站点，却发现这是因为服务器资源回收率低而导致会话状态丢失（当然，您在会话中存储的越多，服务器资源越少用完。记住，如果它可能出错，那么它可能会在某个时候出错！

这就是为什么我现在通常将状态服务器用于除琐碎的会话数据之外的任何事情。我发现的唯一真正的缺点是您需要将类标记为可序列化，但这通常是微不足道的。它也有点慢，但在大多数情况下可以忽略不计。

在 IIS MSDN 博客上有一篇很好的文章。

于 2010-04-26T15:13:48.280 回答
4

优点：
1.可以跨机器访问相同的会话状态。
2. 重新加载app_pool后会话状态相同。

缺点：
1. 比进程模式慢。
2. 会话状态中的所有对象都必须是可序列化的。

于 2010-04-26T14:37:53.880 回答
4

ASP.NET 中会话的缺点

  • 每个变量都存储为对象。这意味着您需要在读取会话变量时将 Object 转换为某种类型。

  • 除此之外，如果会话为空，则 Object 将为空。在读取会话变量之前，您需要检查它是否为空。即使变量之前已初始化，它也可能为 null，因为会话已过期。尝试使用空会话值可能会返回异常。如果会话变量的值为 null，通常的做法是使用一些默认值而不是无意义的 null。如果 value 不为 null，则必须将其转换为适当的类型，因为所有会话变量都是对象类型。在做所有这些事情的时候，你应该注意避免硬编码。有关以可扩展和可维护的方式读取和写入会话变量的更多信息，您可以在如何写入、读取和删除会话状态变量教程中阅读。

  • 变量名是字符串类型。如果您硬编码变量的名称，则可以选择在某处犯类型错误。问题是，如果您尝试读取不存在的会话变量，ASP.NET 将不会返回任何异常或警告。它只会创建具有空值的错误名称的新变量。这些类型的错误可能很难找到。

  • 会话数据不应用于存储敏感数据。恶意用户有可能获取常规访问者的会话 ID。如果会话状态用于存储诸如“是否允许访问管理区域”之类的信息，攻击者可以看到网站的敏感数据、其他人的私人数据、编辑数据库、删除内容等。

  • 如果使用 InProc 模式，会话很容易耗尽所有服务器资源，从而降低网站性能。

状态服务器

SQL Server 是所有模式中最可靠的。如果 ASP.NET 重新启动，但如果 SQL Server 重新启动，会话数据将保持不变。

SQL Server 也是最具可扩展性的选项。

SQL Server 通常在共享主机方案中可用

自定义模式

您可以完全控制会话。甚至可以创建自定义会话 ID。

您可以支持不同的数据源。这对于将会话数据存储在其他数据库（如 Oracle、MySQL、MS Access 等）上可能很有用。

有关任何其他详细信息，您可以单击此处查看 ASP.NET 会话状态的优势。希望我的回答对你有帮助。！:)

于 2015-01-21T04:39:59.883 回答
0

另一个缺点是，如果您跨场执行 1 个远程状态服务器，您可能会遇到单点故障。即使不是农场，它仍然值得在本地运行以生存 app_pool IMO。我们赶上了可序列化的部分，所以一定要注意。

此外，请留意 Windows Server AppFabric 的发布，因为它将具有复制/分布式状态服务器的替代品。据说是 1H2010 的 RTM。

于 2010-04-26T14:49:15.277 回答