Azure EF核心3.1.14循环冷启动

我们已经在Azure云上部署了一个非常简单的.NET CORE 3 Web API应用程序。该应用程序是一个web api，并与托管在Azure中的非常简单的SQL server数据库进行通信。我们注意到两个主要的性能问题

所有API调用都会转到DB进行读或写操作。这些表只包含4行和5行，查询只是基本的选择和插入查询，没有连接

对API的第一次调用非常慢（在大小为10的表中查询1条记录需要30秒），我们添加了计时器，并注意到DB调用占用了99.99%的时间。因此，我使用了Azure Data Studio Profiler，并意识到查询在大约29.90秒后到达SQL Server。所以问题不在于查询本身。此外，第二次、第三次查询等速度非常快，返回时间不超过30毫秒。因此，问题不在于Web应用程序和Azure SQL数据库之间的互联网连接

更大的问题是，如果停止调用API 2-3分钟，然后再进行另一次调用，那么第一次查询也需要30秒。但随后的查询速度更快

如果这只发生在w3wp.exe启动时，那么我不会担心，但是如果对API的请求在2-3分钟内停止，那么它会再次关闭。这令人担忧

我们总是在片场上说“是”

我尝试在Azure中为web应用收集.NET跟踪，但这给了我一个奇怪的错误

以下是安装在与EF相关的VS解决方案中的Nuget软件包版本

下面是SQL Server定价层

是否有其他方法可以收集Azure Web APP的跟踪。我真的需要在30秒内查看代码的调用堆栈才能继续。我可以进入库杜等地

谢谢

更新日期：2021年5月3日至8日

我已经发布了我自己问题的答案。这可能不是其他面临类似问题的人的根本原因，但至少有一个方面需要调查

更新日期：2021年5月2日至7日

在按照Ivan的建议添加EF Core日志记录后，他认为打开连接花费的时间太长是对的？为什么呢？如何阻止这种情况发生

更新日期：2021年5月1日至7日

Jason Pan-我们正在使用应用程序服务计划，这是唯一托管在那里的应用程序。计划是P1V2（）

Ivan Stoev-是的，因为.NET跟踪由于我的问题中解释的某些原因无法工作，我们捕获了App Insights Profiler跟踪以捕获调用堆栈，根据调用堆栈，与SQL server的连接似乎在30秒后打开。因此，我在代码中做了两个更改：

a。从通过DI进行上下文注入的存储库类中删除了IDisposable。在进入Dispose方法之前，我在上下文类上调用Dispose

b。我将services.AddDbContext替换为services.AddDbContextPool

然后，我编写了一个测试程序，每2到4分钟随机调用一次API方法，持续1小时，只有一次调用耗时30秒，其余21次调用耗时数毫秒

但我的下一步是运行24小时测试（例如，每2-7分钟打一次电话），看看这是侥幸还是真正的解决方案

---

好的，请发布我问题的答案。事实证明，web应用程序、应用程序服务计划、sql server或实体框架没有问题。我对我的应用程序和另外一个没有任何问题的应用程序进行了网络跟踪，并用网络监视器打开了它。我们注意到他们正在走不同的道路。查看IP地址后，我们发现另一个应用程序有一个虚拟网络设置。您可以通过转到应用程序服务计划，然后单击左侧菜单栏中的“网络”选项来了解这一点。然后为vNet选择第一个。一旦我们配置了vNet，那么所有的响应都在<1秒之内

---

我一个接一个地疏忽了。Auth0调用有时也需要14秒。当我试着从KUDU运行

tcping google.com

时，有时也会超时。但是在其他web应用程序中运行良好。

这听起来像是连接问题（当连接未合并时）。如果您打开并检查EF Core日志记录会很好，因为它会分别显示连接打开和SQL查询执行时间。您使用的是哪一层，

Free

，

Basic

，或者

Standard

？Azure SQL数据库的哪一层？@DavidBrowne-Microsoft-标准S0:10DTUs@IvanStoev-我已在答复中答复了你的建议。另外，如何使EF岩芯测井工作？它是使用-EnableSensitiveDataLogging（）方法还是其他方法？