天蓝色会话和应用程序池回收答案

【问题标题】：azure session and application pool recycle天蓝色会话和应用程序池回收
【发布时间】：2011-11-09 04:30:10
【问题描述】：

我将开发机器上的会话从 InProc 更改为 SQL Server。我这样做的原因之一是，如果应用程序池会回收，我会在重新启动时再次使用会话。当然，SQL 会话状态的缺点是性能（至少与 InProc 相比）。

如果我迁移到 Azure，我是否 1) 仍然需要担心应用程序池回收，2) 仍然认为 SQL 会话是最好的方法，以及 3) Azure 是否有更好的选择。

谢谢。

【问题讨论】：

标签： asp.net azure

【解决方案1】：

1) 仍然需要担心应用程序池回收 - 是的。但是您可以配置回收间隔。默认情况下，我认为 IIS 每 22 小时回收一次应用程序池

2) 仍然认为 SQL 会话是最好的方法 - 是的。没有（看下一个问题）

3) Azure 是否有更好的选择。 - 取决于，但您可以考虑将 Windows Azure AppFabric 缓存用于会话状态。

看看： http://www.nuget.org/List/Packages/System.Web.Providers 适用于 SQL Azure 的提供程序。和 http://msdn.microsoft.com/en-us/gg457897 使用 Azure Appfabric 缓存作为会话状态。

编辑： 考虑到limits for Azure AppFabric Cache，我可以肯定的是，每个 azure 实例中始终存在一个用于 Azure AppFabric 缓存的单一连接。

【讨论】：

如果“易受攻击”是指“会话是否在应用程序池回收时过期” - 答案应为“否”。没有理由在应用程序池回收时清除会话，因为会话 ID 与 cookie 或通过 URI 一起携带，并且会话对象保存在与 IIS 工作进程不同的存储中。
好的，很酷，所以 AppFabric = 与 InProc 相同的速度 + 与 SQL 会话相同的可靠性？
好吧。我不会说“相同的速度”。这是你的服务器之外的东西。至于可靠性，可能比 SQL session 还要好。

【解决方案2】：

Astaykov 的回答很好。此外，请注意 Windows Azure 使用无关联负载平衡，这意味着进程内确实不是一个选项。（我可能在一个服务器上有一个会话，但是当我加载下一页时，我可能会登陆另一个没有该会话的服务器。）您确实需要将会话存储在所有服务器共享的位置。 SQL 或 AF Cache 都是好地方。

【讨论】：