实体框架异步方法是否使用 ThreadPool 线程？

Question

我通常EF Core在我的 Web 应用程序中使用许多异步方法，如下所示：

await db.Parents.FirstOrDefaultAsync(p => p.Id == id);

我们知道，ThreadPool默认情况下，初始线程数仅限于 CPU 逻辑内核数。用户请求也由ThreadPool.

由于应用程序中有许多异步调用，我是否应该担心处理用户请求或性能问题？

Answer 1

由于应用程序中有许多异步调用，我是否应该担心处理用户请求或性能问题？

EF Core 为存储库提供异步查询接口。无论是全异步还是特定方法阻塞线程池线程都依赖于 EF 提供程序。SQLServer 的 SqlClient 具有不阻塞线程的基于任务的异步方法。大多数其他提供商也这样做。但是例如对于 EF 内存中提供程序，或者 SQLite 提供程序，它可能是异步过同步，要么同步完成并返回已完成的任务，要么阻塞线程池线程。

所以EF通常不会阻塞你的线程。当您对数据库进行异步调用时，它会释放应用程序的线程来做更多的工作。喜欢处理额外的请求。如果您对数据库的并发请求过多，则每个请求将开始花费更多时间。

发生这种情况时，您需要有一种机制来减慢对数据库的新请求的速度，否则您将进入不良状态。数据库服务器所在的EG有2000个正在运行的请求，其中大部分代表已经放弃和超时的客户端。由于所有旧请求，新请求没有得到及时处理。

通常，当您将并发增加到某个点时，吞吐量会增加，但超过该点，整体吞吐量会下降，有时会急剧下降。像这样的东西：

由您决定限制整体并发以防止吞吐量严重下降。最好提前失败一些请求（例如使用 HTTP 503），而不是全部接受它们并且不在您的 SLA 内完成任何请求。

使用同步数据库访问的好处之一是它在数据库交互期间占用一个应用程序线程，自动向请求流添加背压。当所有线程池线程都忙时，请求必须等待线程池线程实际上是一件好事。当你完全异步时，这个控制就会消失，你需要考虑替换它。

ASP.NET Core 目前没有内置限制。您的 Web 服务器主机可能有一些，例如，SqlConnection 的连接池限制用于限制每个应用程序实例的并发请求数。但是您必须有一些东西可以让您以有序的方式处理请求量的激增。