EF Core 3.1.14 反复冷启动 [英] EF Core 3.1.14 Recurring Cold Start
问题描述
我们已将一个非常简单的 .NET CORE 3 Web API 应用程序部署到 Azure Cloud.该应用程序是一个 Web api，并且还与托管在 Azure 中的一个非常简单的 SQL 服务器数据库进行通信.我们注意到两个主要的性能问题
所有 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 秒的代码调用堆栈才能继续前进.我可以访问 KUDU 等.
谢谢.
更新 3 - 2021 年 5 月 8 日
我已经发布了我自己问题的答案.对于其他面临类似问题但至少需要研究 1 个领域的人来说，这可能不是根本原因.
更新 2 - 2021 年 5 月 7 日
按照 Ivan 的建议添加 EF Core 日志记录后，他说打开连接花费的时间太长是对的吗?这是为什么?以及如何阻止这种情况发生?
更新 1 - 2021 年 5 月 7 日
Jason Pan - 我们正在使用应用服务计划，这是在那里托管的唯一应用程序.该计划是 P1V2 (
好的，发布我的问题的答案.结果证明 Web 应用程序、应用程序服务计划、sql server 或实体框架都没有问题.我对我的应用程序和其他 1 个没有任何问题的应用程序进行了网络跟踪，并使用网络监视器打开了它.我们注意到他们正在走不同的道路.在查看 IP 地址后，我们意识到另一个应用程序具有虚拟网络设置.您可以通过转到您的应用服务计划，然后单击左侧菜单栏中的网络选项来查看.然后为 vNet 选择第一个.一旦我们配置了 vNet，那么所有响应都在 <1 秒.
我又一次疏忽了.Auth0 调用有时也需要 14 秒.当我尝试从 KUDU 运行 tcpping google.com 时，有时也会超时.但对其他网络应用程序运行良好.
We have deployed a very simple .NET CORE 3 Web API application to Azure Cloud. The application is a web api and talks to a very simple SQL server database hosted in Azure as well. There are two main performance problems we are noticing
All API calls go to DB for either read or write operations. The tables only contain 4 and 5 rows and the queries are just basic select and insert queries with no joins.
The first call to the API is very slow (30 seconds to query 1 record in a table of size 10) and we added the timer and noticed it is the DB call that is taking 99.99% of the time. So I used the Azure Data Studio Profiler and realized that the query reached SQL Server after like 29.90 seconds. So the issue is not the query itself. Also, the second, third query etc. are super fast and return within < 30 milli-seconds. So the issue is not the internet connectivity between the Web App and the Azure SQL Database.
The bigger problem is that, if you stop calling the API for say 2-3 minutes and then do another call, then again the first query takes 30 seconds. But the subsequent queries are faster.
If this was only happening when w3wp.exe starts then I wouldn't be concerned but if the requests to the API stop coming for 2-3 minutes then again it is down. This is of concern.
We have Always ON set to Yes.
I tried collecting .NET Trace in Azure for the web app but this is giving me this weird error.
Here are the Nuget package versions installed in the VS solution related to EF.
Here is the SQL Server pricing tier.
Is there any other way to collect trace for Azure Web APP. I really need to see the call stack of the code for those 30 seconds to move forward. I have access to KUDU etc.
Thanks.
UPDATE 3 - 8th May 2021
I have posted the answer to my own question. This may not be root cause for other people who face similar problem but at least 1 area to look into.
UPDATE 2 - 7th May 2021
After adding EF Core logging as suggested by Ivan, he is right that the opening of connection is taking too long? Why is that? And how to stop that from happening?
UPDATE 1 - 7th May 2021
Jason Pan - We are using App Service Plan and this is the only application hosted there. The plan is P1V2 (https://azure.microsoft.com/en-us/pricing/details/app-service/windows/).
Ivan Stoev - Yes since the .NET Trace is not working for some reason as explained in my question, we captured the App Insights Profiler Trace to capture the call stack and as per call stack it appears that the connection to the SQL server was opened after 30 seconds. So I made two changes in my code:
a. Removed IDisposable from our Repository class that was having our context inject through DI. Before inside the Dispose method, I was calling Dispose on our context class.
b. I replaced services.AddDbContext with services.AddDbContextPool
I then wrote a test program to call the API method randomly once every 2 to 4 mins for 1 hour and only 1 call took 30 seconds and the remaining 21 took few milli-seconds.
But my next step is to run a 24 hours test (1 call every 2-7 mins for example) to see if this was just fluke or actually the solution.
Ok so posting an answer to my question. It turned out that there was no issue with web application, app service plan, sql server or entity framework. I took a network trace of my application and 1 other application which doesn't have any issue and opened it with network monitor. We noted that they are taking different paths. After looking into the IP address we realized that the other application had a virtual network setup. You can see that by going to your app service plan and then click on Networking option in the left menu bar. And then choose the first one for vNet. Once we configured vNet, then all responses were within < 1 second.
There was one another oversight by me. The Auth0 calls were also taking 14 seconds sometimes. And when I tried running tcpping google.com from KUDU that timed out sometimes as well. But was working fine for other web applications.
这篇关于EF Core 3.1.14 反复冷启动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
