azure - Azure Functions ServiceBus 触发器缩放行为

问题描述

我们目前正在我们的 Azure Function App 上运行负载测试，但吞吐量不是我们预期的。

Function App 中有多个函数，但流量最多的函数是一个具有事件中心触发器，另一个具有使用会话启用队列中的消息的服务总线触发器。

当系统处于负载状态时，会话启用队列中的消息在队列中等待长达 10 分钟，直到它们被消费函数处理。

我知道在 host.json 中有一些设置可以调整这种行为，但它仍然远离我们的预期。

这是我们的 host.json

{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    }
  },
  "extensions": {
    "serviceBus": {
      "prefetchCount": 100,
      "sessionHandlerOptions": {
        "autoComplete": true,
        "messageWaitTimeout": "00:00:30",
        "maxAutoRenewDuration": "00:55:00",
        "maxConcurrentSessions": 200
      },
      "batchOptions": {
        "maxMessageCount": 1000,
        "operationTimeout": "00:01:00",
        "autoComplete": true
      }
    }
  }
}

所以我希望函数应用程序同时处理多达 200 个会话，但事实上，虽然函数运行时提供了很多实例，但它们中的大多数似乎都坐在那里闲置。所以对我来说，似乎还有另一个设置限制了 Function App 的吞吐量。

我知道如果我们将函数拆分为单独的函数应用程序会提高性能，但由于这两个函数的负载非常相似，我的计划是将这一步推迟到稍后阶段，并且仍然通过单个函数应用程序获得可接受的吞吐量。

我们在 .NET Core 3.1 上使用 Azure Functions 3

Microsoft.Azure.Functions.Extensions 1.1.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus 5.0.0
Microsoft.Azure.WebJobs.Extensions.EventHubs 5.0.0

在 Windows 消费计划上。

感谢您提供有关如何实现可接受的吞吐量的任何提示。

标签： azureazure-functionsazureservicebus

我发现在 ServiceBus-Triggered 函数中处理批处理消息（接收 ServiceBusMessage[] 而不是单个实例）以及启用的会话会对可伸缩性产生巨大的负面影响。

将其更改为单个实例后，系统的行为符合预期，并且 host.json 中的 sessionHandlerOptions 得到了尊重。

我想知道这是什么原因。我想这可能与 Azure Function Instances 从服务总线租用一些会话来处理但在文档中找不到任何内容的情况有关。

azure - Azure Functions ServiceBus 触发器缩放行为

问题描述

解决方案

推荐阅读