Azure Functions 中的 DbContext 池

Question

我有一个按消耗计划运行的 Azure 函数。当函数负载很重时，我一直收到System.InvalidOperationException这样的消息The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

我正在使用依赖项注入，到目前为止，我一直在使用AddDbContextPool. 是否建议将 DbContext 池用于 Azure Functions，还是我应该使用AddDbContext？

我的 SQL Server 的连接字符串仅指定服务器和身份验证，这意味着默认情况下也应启用连接池。Azure Functions 是否也建议使用连接池？

Answer 1

显然，AddDbContextPool 与连接池不同。相反，它是一个 dbcontext 池：/sf/answers/3391094451/

另外，根据https://learn.microsoft.com/en-us/azure/azure-functions/manage-connections#sqlclient-connections，EF 和 EF Core 默认实现连接池，因为它们使用 ADO.NET，这就是默认为 ADO.NET。

您的函数代码可以使用 SQL Server 的 .NET Framework 数据提供程序 (SqlClient) 来连接到 SQL 关系数据库。这也是依赖 ADO.NET 的数据框架（例如实体框架）的底层提供程序。与 HttpClient 和 DocumentClient 连接不同，ADO.NET 默认实现连接池。但由于您仍然可能会耗尽连接，因此您应该优化与数据库的连接。有关详细信息，请参阅 SQL Server 连接池 (ADO.NET)。

我认为你最好的选择是降低并发性，就像你在评论中已经说过的那样，但除此之外，我认为重要的是要注意连接池是在客户端管理的（在本例中是 Azure Func）： SQL Server：连接池在哪里：在.net端或服务器端。因此，虽然您的 func 应用程序将能够利用连接池，但 func 应用程序的每个实例在扩展时都将拥有自己的连接池。因此，连接池的可扩展性优势不如一个客户端应用程序管理单个连接池那么大。

因此，为了从 func 应用程序的每个实例的连接池中获得更大的好处，您应该为每个服务总线触发器做更多的工作。例如，在同一触发器下将多个查询一起批处理，而不是每个触发器 1 个查询。此外，如果您在其他触发器中进行写入，则可以在 1 个 func 应用触发器中将多个更新/插入操作一起批处理。据此，42 个非查询操作是 EF Core 中每批的最佳大小：https://learn.microsoft.com/en-us/ef/core/performance/efficient-updating#batching

但比这更好的是使用表值参数一次对数百/数千条记录进行批量更新。进行这些更改后，由于达到连接限制而导致的错误消失了。