EF核心3.1.14反复冷启动

Question

我们已经向Azure部署了一个非常简单的.NET核心3WebAPI应用程序。该应用程序是一个web，并与一个托管在Azure中的非常简单的SQL服务器数据库进行对话。我们注意到有两个主要的性能问题

所有API调用都会转到DB进行读或写操作。表只包含4行和5行，查询只是基本的select和insert查询，没有联接。

1. --对API的第一次调用非常慢(查询10大小表中的1条记录需要30秒时间)，我们添加了计时器，注意到数据库调用占用了99.99%的时间。因此，我使用Azure，并意识到查询在29.90秒后到达Server。所以问题不是查询本身。另外，第二次、第三次查询等都是超快的，并在< 30毫秒内返回.因此，问题不在于Web与Azure数据库之间的互联网连接。

1. 更大的问题是，如果您停止调用API 2到3分钟，然后再执行另一个调用，那么第一个查询需要30秒。但是后续的查询速度更快。

如果只有在w3wp.exe启动时才会发生这种情况，那么我不会担心，但是如果对API的请求停止2到3分钟，那么它就会再次下降。这是令人关切的。

我们一直在为“是”做准备。

我尝试收集.NET跟踪在Azure的网页应用程序，但这是给我这个奇怪的错误。

​

​

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

​

​

这里是Server定价层。

​

​

有没有其他方法为Azure Web应用程序收集跟踪信息。我真的需要看到这30秒代码的调用堆栈才能向前推进。我可以进入古都等。

谢谢。

更新2021年5月3日至8日

我已经把我自己的问题的答案贴了出来。对于面临类似问题的其他人来说，这可能不是根本原因，但至少有一个领域需要研究。

更新2-2021年5月7日

在按照Ivan的建议添加EF核心日志之后，他说连接的打开时间太长是正确的吗？为什么会这样呢？怎样才能阻止这种情况的发生？

更新2021年5月1日至7日

杰森潘-我们正在使用应用程序服务计划，这是唯一的应用程序托管在那里。计划是P1V2 (https://azure.microsoft.com/en-us/pricing/details/app-service/windows/)。

Ivan Stoev --是的，正如我在问题中所解释的那样，由于.NET跟踪不起作用，我们捕获了appears跟踪以捕获调用堆栈，并且根据调用堆栈，到.NET服务器的连接似乎在30秒后打开。因此，我对我的代码做了两个修改：

从我们的Repository类中删除了IDisposable，这个类通过DI注入我们的上下文。在Dispose方法中之前，我在上下文类上调用Dispose。

我用services.AddDbContextPool代替了services.AddDbContextPool

然后我编写了一个测试程序，每2到4分钟随机调用API方法一次，每次1小时，只有1次调用需要30秒，剩下的21次需要几毫秒。

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

​

​

Answer 1

好吧，那就贴出我的问题的答案。结果表明，web应用程序、应用服务计划、sql服务器或实体框架都没有问题。我对我的应用程序和其他没有任何问题的应用程序进行了网络跟踪，并使用网络监视器打开了它。我们注意到他们走的是不同的道路。在查看了IP地址之后，我们意识到另一个应用程序有一个虚拟网络设置。您可以通过转到您的应用程序服务计划，然后单击左边菜单栏中的网络选项来看到这一点。然后为vNet选择第一个。配置vNet之后，所有响应都在<1秒内。

我有另一个疏忽。Auth0通话有时也需要14秒。而当我尝试从KUDU运行tcpping google.com时，有时也会超时。但是对于其他的网络应用程序来说却很好。