gpt4 book ai didi

Azure Functions ServiceBus 触发缩放行为

转载 作者:行者123 更新时间:2023-12-02 05:55:33 25 4
gpt4 key购买 nike

我们目前正在 Azure Function App 上运行负载测试,但吞吐量未达到我们的预期。

函数应用程序中有多种函数,但流量最多的函数是带有事件中心触发器的函数和带有使用来自启用 session 的队列的消息的服务总线触发器的函数。

当系统处于负载状态时, session 启用队列中的消息将在队列中等待最多 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 个 session ,但事实上,尽管 Function Runtime 提供了大量实例,但大多数实例似乎都闲置在那里。所以对我来说,似乎还有另一个设置限制了 Function App 的吞吐量。

Application Insights Monitoring

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

我们在 .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 消费计划。

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

最佳答案

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

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

我想知道这是什么原因。我猜想这可能与 Azure 函数实例从服务总线租用大量 session 来处理但在文档中找不到任何相关内容有关。

关于Azure Functions ServiceBus 触发缩放行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/69972020/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com