实体框架服务器超时答案

【问题标题】：Entity Framework server timeout实体框架服务器超时
【发布时间】：2016-04-10 19:42:59
【问题描述】：

在 Microsoft Azure 上托管基于 Entity Framework 的网站后，我遇到了问题。如果在大约 30 分钟内没有对服务器进行任何调用，服务器将完全停止响应并为所有请求返回内部服务器错误 (500)。

当我在本地运行站点时，这不是问题（我可以让它运行几个小时而没有任何事情发生），当我回到它时它仍然可以工作。我设法通过运行一个每 15 分钟 ping 一次服务器的循环来解决这个问题，但这显然不是一个好的解决方案；所以我的问题是：我可以在哪里以及如何配置我的服务器的连接属性，以防止它在不使用时死机？

我对连接身份验证知之甚少，当我得到的唯一错误是内部服务器错误（它什么也没告诉我）时，我不知道如何解决这个问题。

这里是 Github 上的代码：https://github.com/synthc/UMD.git

【问题讨论】：

我没有遇到过这个问题，但这让我想知道工作线程是否在 30 分钟不活动后被回收。您是否长期保留数据库上下文？
好吧，我没有做任何事情来重新初始化我的数据库上下文，所以我会假设它永远不会被重新分配（这是一件坏事吗？）。
我最近没有使用 Azure 的经验，因此无法直接发表评论。在我的 MVC 应用程序中，数据库上下文在请求的整个生命周期内都存在。这让我可以做一些事情，比如恢复更改，而不必担心干扰其他请求。看看使用 Unity 检索 DBContext。它可以为您处理对象的生命周期。见stackoverflow.com/a/18264598/156755
写得更好，解释得体：stackoverflow.com/a/10588594/156755
在工作期间，你有多少流量。是否有任何其他代码块或系统在数据库上做任何工作。我们有类似的东西，直到我们注意到 EF 搞砸了统计数据。

标签： asp.net sql-server entity-framework azure

【解决方案1】：

我想到了一些想与你分享的事情——Basic 已经指出了其中之一。

始终开启

首先，您的 Web 应用程序似乎“进入睡眠状态”的原因是 Azure Web 应用程序中的一项可以关闭的功能：

您可以阅读更多关于此功能的信息here。

我怀疑在尝试备份您的网络应用程序时出现问题，即您的数据库连接出现问题 - 这会导致 500s。

数据上下文生命周期管理

因此，事实上，正如 Basic 所指出的 - 我建议将依赖注入 (DI) 用于您的实体框架 (EF) 上下文到您的控制器中。这将使 EF 数据上下文具有单个请求的生命周期，从而大大减少上下文进入错误状态。

Ninject 是我最常使用的 DI 容器，这里有一篇关于如何让它与 ASP.NET MVC 一起工作的文章：http://www.davepaquette.com/archive/2013/03/27/managing-entity-framework-dbcontext-lifetime-in-asp-net-mvc.aspx

实体框架执行策略

最后——EF 为数据库提供了不同的执行策略。它为 Azure 上的连接提供了一种特殊的方式。您希望按照此处所述启用SqlAzureExecutionStrategy：https://msdn.microsoft.com/en-us/data/dn456835.aspx。这将更好地处理可能在云中发生的瞬态故障处理。

我很确定，如果你使用所有这些 - 你应该没问题，你 500 应该没有了。

【讨论】：

感谢您的回答。不幸的是，我的 Azure 订阅不允许我使用 Always On（我现在正在考虑升级）。至于依赖注入，我已经在使用 Ninject 将我的自定义存储库绑定到一个接口，然后我将它注入到我的控制器中。这应该是每个请求初始化一次数据库上下文，因为它是在我的存储库中初始化的，对吧？
DI 容器将被配置为为其创建的实例应用生命周期（也称为范围）。对于 NInject，请参阅 object scope documentation，特别是 InRequestScope