使用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会话状态:架构和性能注意事项添加了一些其他信息,会话状态模式的MSDN主题是一个可靠的最新源.

Answer 2

State Server是一个很棒的(!)入门选择.为什么？因为这意味着您的应用程序现在与任何进程外存储模式兼容.

如果您当前正在开发您的网站InProc并希望进入StateServer或SqlServer稍后进入,那么您可能会遇到序列化问题.并非总是如此,但它确实发生了.

一些例子包括(一些已经提到过):

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

因此,最好尽早解决这个问题.它只是配置更改和服务启动; 繁荣!

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

它真的是1分钟工作的好投资.您现在已准备好使用Web场,负载平衡器以及您决定进行原型设计的任何其他会话管理系统.

Answer 3

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

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

IIS MSDN 博客上有一篇关于此的好文章。