Azure Functions静态SqlConnection-正确的扩展方式? [英] Azure Functions static SqlConnection - right way to scale?

问题描述

我将带有队列触发器的Azure功能用于部分工作负载.特定功能查询数据库，这会导致扩展问题，因为对数据库执行ping的大量功能实例导致并发命中了最大允许的Azrue DB连接数.

I'm using Azure Functions with queue triggers for part of our workload. The specific function queries the database and this creates problems with scaling since the large concurrent number of function instances pinging the db results in maximum allowed number of Azrue DB connections being hit constantly.

本文 https://docs.microsoft.com/en-us/azure/azure-functions/manage-connections 将HttpClient列为应设为静态的那些资源之一. 应该使用静态SqlConnection将数据库访问也设为静态以解决此问题，还是通过保持常量连接对象而导致其他一些问题?

This article https://docs.microsoft.com/en-us/azure/azure-functions/manage-connections lists HttpClient as one of those resources that should be made static. Should database access also be made static with static SqlConnection to resolve this issue, or would that cause some other problems by keeping the constant connection object?

推荐答案

还应该使用静态SqlConnection使数据库访问静态化

Should database access also be made static with static SqlConnection

绝对不是.每个函数调用都应该在using块中使用相同的连接字符串打开一个新的SqlConnection.尚不清楚运行时将对您的应用程序的单个实例进行多少个并发的函数调用.但是，如果大于1，则单身SqlConnection是一件坏事.

Definitely not. Each function invocation should open a new SqlConnection, with the same connection string, in a using block. It's not really clear how many concurrent Function Invocations the runtime will make to a single instance of your application. But if it's more than 1, then a singleton SqlConnection is a bad thing.

我确切地想知道哪个限制您在SQL数据库中遇到了连接限制或并发请求限制?在这两种情况下，我都会感到惊讶(不是函数专家)，您会收到这么多并发函数调用，因此可能还会发生其他情况.就像您正在泄漏SqlConnections.

I wonder exactly which limit you're hitting in SQL Database, the connection limit or the concurrent request limit? In either case I'm a bit surprised (not a Functions expert) that you get that many concurrent function invocations, so there might be something else going on. Like you're leaking SqlConnections.

但是阅读函数文档，我的猜测是通过运行函数应用程序的多个实例来扩展函数运行时.您的.NET应用程序可以在单个过程中进行扩展，但这显然不是函数工作的方式. Functions应用程序的每个实例都有其自己的SQL Server ConnectionPool，默认情况下，每个ConnectionPool可以具有100个连接.

But reading the Functions docs, my guess is that the functions runtime is scaling by launching multiple instances of your function app. Your .NET app could scale in a single process, but that's apparently not the way Functions works. Each instance of your Functions app has it's own ConnectionPool for SQL Server, and by default each ConnectionPool can have 100 connections.

也许如果您在连接字符串中严格限制最大池大小"，将不会打开太多连接.当您达到最大池大小"时，对SqlConnection.Open()的新调用将最多阻塞30秒钟，等待池化的SqlConnection可用.因此，这不仅限制了应用程序每个实例的连接使用，而且还限制了负载下的吞吐量.

Perhaps if you sharply limit the Max Pool Size in your connection string, won't have so many connections open. When you hit the Max Pool Size, new calls to SqlConnection.Open() will block for up to 30 seconds waiting for a pooled SqlConnection to become available. So this not only limits the connection use for each instance of your application, it throttles your throughput under load.

这篇关于Azure Functions静态SqlConnection-正确的扩展方式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！