【问题标题】:Azure Functions ServiceBus Trigger Scaling BehaviorAzure Functions ServiceBus 触发器缩放行为
【发布时间】:2021-12-26 12:28:30
【问题描述】:

我们目前正在我们的 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
      }
    }
  }
}

所以我希望 Function App 可以同时处理多达 200 个会话,但事实上,虽然 Function Runtime 提供了很多实例,但它们中的大多数似乎都坐在那里闲置。所以对我来说,似乎还有另一个设置限制了 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 消费计划。

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

【问题讨论】:

    标签: azure azure-functions azureservicebus


    【解决方案1】:

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

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

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

    【讨论】:

      猜你喜欢
      • 2021-02-10
      • 2022-01-19
      • 2018-10-26
      • 1970-01-01
      • 2017-10-29
      • 1970-01-01
      • 2021-02-23
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多