与等效的 Webjobs 相比，队列触发的 Azure Functions 的等待时间非常长

Question

我已将队列触发的 Azure Webjobs 迁移到 Azure Functions。根据我的测量，使用函数从队列中取出消息的等待时间是 5 到 60 倍以上（是的）。

在 Webjob 领域，我观察到 BatchSize、NewBatchThreshold 和 MaxPollingInterval 处于默认值时，队列等待时间通常为亚秒级。

使用我的函数，我看到队列等待时间经常超过 45-60 秒。队列中的项目数与等待时间之间存在相关性。如果队列中的项目数为低个位数，则等待时间过长，即。60 秒以上。尽管我尝试了 BatchSize 和 NewBatchThreshold 的许多不同组合。

一些具体细节：

• webjobs 是 .NET Core 3.1
• 函数是 v3 和 .NET Core 3.1
• 我已经尝试了 Consumption Plan 和 App Service 计划上的 Functions，但我发现等待时间没有区别

为了获得一些科学测量值，我检测了我的函数来记录消息排队的时间以及从队列中检索消息的时间，以获得经过的时间。为了进一步消除变量，我创建了几个完全空的函数——也就是说，队列触发方法的主体只包含记录时间的代码。我在这里也看到了大量的等待时间。

如果我采用队列触发方法并将它们复制并粘贴到 Azure webjob 中，队列等待时间将变为 1 秒或更短。

任何指导？

Answer 1

不确定 Webjobs，但在 Azure Functions 中，将消息添加到队列和拾取消息之间的时间各不相同 - 请查看文档中轮询算法的详细信息：

队列触发器实现随机指数退避算法，以减少空闲队列轮询对存储事务成本的影响。该算法使用以下逻辑：

• 找到消息后，运行时会等待两秒钟，然后检查另一条消息
• 当没有找到消息时，它会等待大约四秒钟，然后重试。
• 在后续尝试获取队列消息失败后，等待时间将继续增加，直到达到最大等待时间（默认为一分钟）。
• 最长等待时间可通过 host.json 文件中的 maxPollingInterval 属性进行配置。对于本地开发，最大轮询间隔默认为两秒。

基于此，您似乎需要减少maxPollingInterval的值- 默认情况下为 60 秒，因此在最坏的情况下，您可以预期最大延迟约为该值。如果将其减少到 X，则添加消息和出队之间的最差时间将在 X 左右（由于不同的开销，可能会多一些）