允许Web场中的会话？ StateServer足够好吗？

Question

首先介绍一下当前环境的背景知识。我们有许多ASP.NET应用程序，所有这些应用程序都在某些方面使用会话。由于流量水平，我们在多个服务器上“负载均衡”，但是，我们的负载平衡设置为使用“Sticky Sessions”，因为当前所有Web应用程序都设置为使用“InProc”进行会话状态。

我们正在考虑在我们的负载均衡器上删除“Sticky Sessions”配置，因为我们的流量负载服务器可以并且确实会过载。我们希望采用更加平衡的方法，但必须能够使用会话。

我知道会话状态的SqlServer会起作用，但由于我们无法控制的原因，我们无法使用SqlServer来存储我们的状态。在研究中似乎StateServer是我们最好的选择。我们有一个额外的服务器，周围有大量的内存。此服务器可以是整个Web群集的StateServer。我们只想了解以下事项。

1。）除了从InProc切换到StateServer的任何潜在的序列化问题之外，是否存在丢失会话对象或在上面列出的环境中产生错误的主要已知问题？

2。）除了单点故障，性能稍慢，我们需要注意使用StateServer的任何其他问题。

3。）是否有任何指标显示三种状态存储之间的性能差异？

Answer 1

这是关于asp.net状态的一个不错的常见问题：http://www.eggheadcafe.com/articles/20021016.asp

从该文章中，以下是有关StateServer的一些信息：

• 在Web场中，确保所有Web服务器中都具有相同的MachineKey。有关如何操作，请参阅KB 313091。
• 此外，请确保您的对象可序列化。有关详细信息，请参阅KB 312112。
• 对于要在Web场中的不同Web服务器上维护的会话状态，IIS Metabase中网站的应用程序路径（例如\ LM \ W3SVC \ 2）在Web场中的所有Web服务器中应该相同。有关详细信息，请参阅KB 325056

Answer 2

我只使用了sql和in-proc。但是这些在使用sql server时适用的3也适用：

• 避免在会话中存储太多信息，因为它会影响序列化和通过网络传输的数据。
• 确保您没有任何依赖于Session_onEnd的内容。这不适用于进程外会话。
• 关闭不使用它的网页上的会话。这对进程内会话没有任何影响，但对于进程外，它将为您节省很多。

Answer 3

确保您的服务器etag ID在Web场中同步，否则客户端浏览器的缓存将会被打乱。

您是否详细检查过您的代码，以确保所有内容都可以在进程外和LAN中有效地序列化？

您是否正在解决系统中的主要性能问题？我问，因为数据库是典型的争用来源。

我摆脱粘性会话的主要动机是操作灵活性，即绕过有问题的服务器或部署软件升级。因此，实施中央会话状态服务可确保您从操作角度充分利用。

Answer 4

根据我的经验，我们发现原生状态服务器甚至使用SQL Server进行会话是一个非常可怕的情况，因为两者都存在问题（主要是性能）。顺便说一下，我们也在使用粘性会话。

我认为您可以探索其他产品，以达到最佳效果。免费选项为Velocity，但仍未发布。 另一个全面但经过验证的产品将是（实际上非​​常昂贵）NCache。这甚至可以帮助你的服务成本更低，如果你使用他们的API，它将是更好的结果。

看看哪个最适合你。

关于SQL Server，如果你有足够多的点击量，你的服务器很快就会死掉（我相信你已经有一些点击让你做了Web Farm，或者你只是为了冗余而这样做）

结论：我们正在评估Velocity，因为NCAchce非常昂贵。然而，优势是巨大的。

Answer 5

我们将StateServer用于一个非常小的Web场，只有两个节点可供几百个用户使用。

我不负责它的操作，但我记得两年内只有两个问题，因为它崩溃了，必须重新启动服务。

Answer 6

我想再接受一个接受的答案：

• 确保框架dll的版本相同。

在我的情况下，System.Web dll版本不同，因为在服务器场的其中一个服务器上跳过了一些Windows更新。