我们已将一个非常简单的 .NET CORE 3 Web API 应用程序部署到 Azure 云。该应用程序是一个 Web API，并与 Azure 中托管的一个非常简单的 SQL 服务器数据库进行通信。我们注意到两个主要的性能问题
所有 API 调用都会进入数据库进行读或写操作。这些表仅包含 4 行和 5 行，查询只是基本的选择和插入查询，没有连接。
对 API 的第一次调用非常慢（在大小为 10 的表中查询 1 条记录需要 30 秒），我们添加了计时器，并注意到数据库调用占用了 99.99% 的时间。因此，我使用了 Azure Data Studio Profiler，并意识到查询在大约 29.90 秒后到达了 SQL Server。所以问题不在于查询本身。此外，第二个、第三个查询等速度非常快，并且在
The 更大的问题也就是说，如果您停止调用 API 2-3 分钟，然后再进行一次调用，那么第一个查询将再次花费 30 秒。但后续查询速度更快。
如果这仅在 w3wp.exe 启动时发生，那么我不会担心，但如果对 API 的请求停止 2-3 分钟，那么它会再次关闭。这是值得关注的。
我们将“始终开启”设置为“是”。
我尝试在 Azure 中收集 Web 应用程序的 .NET Trace，但这给了我这个奇怪的错误。
以下是VS解决方案中安装的与EF相关的Nuget包版本。
这是 SQL Server 定价层。
还有其他方法可以收集 Azure Web APP 的跟踪吗？我确实需要查看这 30 秒的代码调用堆栈才能继续。我可以访问 KUDU 等。
Thanks.
更新 3 - 2021 年 5 月 8 日
我已经发布了我自己问题的答案。对于其他面临类似问题的人来说，这可能不是根本原因，但至少有 1 个方面需要调查。
更新 2 - 2021 年 5 月 7 日
按照 Ivan 的建议添加 EF Core 日志记录后，他认为打开连接花费的时间太长是对的吗？这是为什么？以及如何阻止这种情况发生？
更新 1 - 2021 年 5 月 7 日
杰森·潘- 我们正在使用应用程序服务计划，这是那里托管的唯一应用程序。计划是P1V2（https://azure.microsoft.com/en-us/pricing/details/app-service/windows/).
伊万·斯托耶夫- 是的，由于 .NET Trace 由于某种原因无法正常工作，正如我的问题中所解释的，我们捕获了 App Insights Profiler Trace 以捕获调用堆栈，并且根据调用堆栈，似乎与 SQL Server 的连接在 30 秒后打开。所以我对我的代码做了两处更改：
A。从我们的 Repository 类中删除了 IDisposable，该类通过 DI 进行上下文注入。在使用 Dispose 方法之前，我在上下文类上调用 Dispose。
b.我用 services.AddDbContextPool 替换了 services.AddDbContext
然后我编写了一个测试程序，每 2 到 4 分钟随机调用一次 API 方法，持续 1 小时，只有 1 次调用花费了 30 秒，其余 21 次调用花费了几毫秒。
但我的下一步是运行 24 小时测试（例如，每 2-7 分钟调用 1 次），看看这只是侥幸还是实际上是解决方案。
好的，所以发布我的问题的答案。事实证明，Web应用程序、应用程序服务计划、sql服务器或实体框架都没有问题。我对我的应用程序和其他 1 个没有任何问题的应用程序进行了网络跟踪，并使用网络监视器将其打开。我们注意到他们正在走不同的道路。查看 IP 地址后，我们意识到另一个应用程序具有虚拟网络设置。您可以通过转到您的应用程序服务计划，然后单击左侧菜单栏中的“网络”选项来查看这一点。然后选择第一个用于 vNet。配置 vNet 后，所有响应都会在 1 秒内完成。
我还有一个疏忽。 Auth0 调用有时也需要 14 秒。当我尝试跑步时tcpping google.com来自 KUDU 的有时也会超时。但对于其他网络应用程序来说工作得很好。
