5

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

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

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

一些具体细节：

  • 网络作业是 .NET Core 3.1
  • 函数是 v3 和 .NET Core 3.1
  • 我已经尝试过 Consumption Plan 和 App Service 计划中的功能，我发现等待时间没有差异

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

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

有什么指导吗？

4

1 回答 1

1

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

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

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

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

于 2020-10-28T10:00:24.300 回答