使用ASP.NET会话状态服务器（而不是InProc）的优点和缺点？

Question

在开始使用会话状态服务器之前，为了使我的应用程序中的会话状态比InProc状态更强大，我想找到一个优点和缺点列表进行评估。

更新1 ：还有关于还原应用程序池的问题吗？

更新2 ：会话的长寿及其结局如何？

Answer 1

这是对Rob Howard的ASP.NET Session State文章的三个选项的利弊进行的规范分析：

  

  

• 正在处理。在进程中将表现最佳，因为会话状态内存保留在ASP.NET进程中。对于托管在单个服务器上的Web应用程序，保证用户可以重定向到正确服务器的应用程序，或者会话状态数据不重要的应用程序（在某种意义上可以重新构建或重新填充） ，这是可供选择的模式。

  

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

  

• SQL Server 。当数据的可靠性对应用程序的稳定性至关重要时，最好使用此模式，因为数据库可以针对故障情况进行集群。性能不如过程快，但权衡是更高的可靠性。

  

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

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

Tim Sneath的ASP.NET Session State: Architectural and Performance Considerations添加了一些其他信息，MSDN topic on Session State Modes是一个可靠的最新来源。

Answer 2

状态服务器是伟大的（！）选择。为什么？因为这意味着您的应用程序现在与任何进程外存储模式兼容。

如果您目前使用InProc开发自己的网站，并希望稍后进入StateServer或SqlServer，则可能会出现序列化问题。并非总是如此，但它确实发生了。

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

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

因此，最好尽早解决这个问题。它只是配置更改和服务启动;吊杆！

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

这对1分钟的工作真的很好。您现在可以使用Web场，负载平衡器以及您决定进行原型设计的任何其他会话管理系统。

Answer 3

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

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

Answer 4

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

这就是为什么我现在通常使用State Server来处理琐碎的会话数据。我发现唯一真正的缺点是你需要将类标记为可序列化，但这通常是微不足道的。它也有点慢，但在大多数情况下这可以忽略不计。

IIS MSDN博客上有a good article about this。

Answer 5

ASP.NET中会话的缺点

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

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

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

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

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

StateServer

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

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

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

自定义模式

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

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

您可以click here to view ASP.NET Session state advantages获取任何其他详细信息。希望我的回答能帮助你。 :)

Answer 6

另一个缺点是，如果跨服务器场执行1个远程状态服务器，则可能会出现单点故障。即使不是一个农场，它仍然值得在本地运行只是为了生存app_pool IMO。我们陷入了可序列化的部分，所以请注意它。

此外，请密切注意Windows Server AppFabric的发布，因为它将替换复制/分布式状态服务器。据称是2010年上半年的RTM。