c# - 与等效的 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

我已经尝试了消费计划和应用服务计划上的函数，但我发现等待时间没有区别

为了获得一些科学测量值，我检测了我的函数来记录消息排队的时间以及从队列中检索消息的时间，以获得耗时。为了进一步消除变量，我创建了几个完全空的函数——也就是说，队列触发方法的主体只包含记录时间的代码。我在这里也看到了大量的等待时间。
如果我采用队列触发方法并将它们复制并粘贴到 Azure webjob 中，队列等待时间将变为 1 秒或更短。
任何指导？

Answer 1

不确定 Webjobs，但在 Azure Functions 中，将消息添加到队列和接收消息之间的时间各不相同 - 请查看 polling algorithm from the documentation 的详细信息:

The queue trigger implements a random exponential back-off algorithm to reduce the effect of idle-queue polling on storage transaction costs. The algorithm uses the following logic:

• When a message is found, the runtime waits two seconds and then checks for another message
• When no message is found, it waits about four seconds before trying again.
• After subsequent failed attempts to get a queue message, the wait time continues to increase until it reaches the maximum wait time, which defaults to one minute.
• The maximum wait time is configurable via the maxPollingInterval property in the host.json file. For local development the maximum polling interval defaults to two seconds.

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