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