问题描述
我已经将队列触发的Azure Webjob迁移到Azure Functions。根据我的测量，使用“功能”将消息从队列中拔出的等待时间要长5倍至60倍以上（是的）。
在Webjob领域，我观察到BatchSize，NewBatchThreshold和MaxPollingInterval为默认值，队列等待时间通常不到一秒。
通过我的功能，我看到队列等待时间通常超过45-60秒。 队列中的项目数与等待时间之间存在相关性。如果队列中的项目数为低个位数，则等待时间过多，即。超过60秒。尽管我尝试了很多 BatchSize和NewBatchThreshold的不同组合。
一些具体细节：
为了进行一些科学的测量，我对函数进行了记录，以记录消息排队的时间以及从队列中检索消息的时间，以获取经过的时间。为了进一步消除变量，我创建了几个完全空的函数-即，队列触发方法的主体只包含用于记录时间的代码。我也在这里看到了大量的等待时间。
如果我采用队列触发的方法并将其复制并粘贴到Azure webjob中，则队列等待时间将变为1秒或更短。
有指导吗？
解决方法
不确定Webjobs，但在Azure Functions中，将消息添加到队列与接收消息之间的时间各不相同-请查看polling algorithm from the documentation的详细信息：
队列触发器实现了随机指数补偿算法 减少空闲队列轮询对存储事务的影响 费用。该算法使用以下逻辑：
- 找到消息后，运行时将等待两秒钟，然后检查另一个 消息
- 未找到任何消息时，它将等待约四秒钟 再试一次。
- 在随后尝试获取队列消息失败之后， 等待时间持续增加，直到达到最大等待时间 时间，默认为一分钟。
- 最大等待时间为 可通过host.json中的maxPollingInterval属性进行配置 文件。对于本地开发，最大轮询间隔默认为 两秒钟。
基于此，看来您需要减小 maxPollingInterval 的值-默认为60秒，因此在最差的情况下，您可以期望最大延迟在该值附近。如果将其减少到X，则在添加消息和出队之间最差的时间将是X左右（由于开销不同，可能会更长一些）