Azure 服务总线队列性能

Posted 2023-04-13

【中文标题】Azure 服务总线队列性能

【英文标题】：Azure Service Bus Queue Performance

【发布时间】：2020-12-17 13:15:20

【问题描述】：

我正在使用 Azure 服务总线队列来满足我的一项要求。要求很简单，一个 azure 函数将充当 API 并在队列中创建多个作业。该功能是可扩展的，可按需创建新实例。微服务创建的作业将由 Windows 服务处理。所以发送者是Azure函数，接收者是windows服务。由于 azure 函数是可扩展的，因此将并行执行多个函数。因此，创建到队列中的作业数量将是并行的，并且可能每 500 毫秒就有一个作业。 Windows 服务是一个单实例，它是一个 Queue 侦听器，侦听此 Queue 并并行执行。所以，发送者的数量可能更多，接收者是一个实例。而且每个作业可以并行运行必须是有限的（4，因为它需要更多的时间和CPU）现在，我正在使用具有以下配置的Aure Service Bus Queue。我怀疑哪种配置可以为这个特定要求提供最佳性能。

删除队列中的作业对我来说不是问题。那么，我可以使用 Delete 代替 Peek-Lock 吗？

另外，现在，监听器接收到的项目数量是不按顺序排列的。我想保持创建它的顺序。我的要求是最高性能。由 windows 服务完成的工作是一个 CPU 密集型任务，这就是为什么我限制为 4，因为系统是 4 核。

最大传递计数：4，消息锁定持续时间：5 分钟，MaxConcurrentCalls：4（在侦听器中）。我是服务总线的新手，我需要对此提出建议。

还有一个疑问是，让我们假设侦听器并行执行了 4 个作业并开始执行。一个作业完成了它的执行并变成了完成状态。因此侦听器将立即选择下一项或等待所有 4 个作业完成 (MaxConcurrentCalls: 4)。

【参考方案1】：

删除队列中的作业对我来说不是问题。那么，我可以使用 Delete 代替 Peek-Lock 吗？

在PeekLock 接收模式下接收消息的性能将低于ReceiveAndDelete。您将保存到代理的往返行程以完成消息。

最大传递计数：4，消息锁定持续时间：5 分钟，MaxConcurrentCalls：4（在侦听器中）。我是服务总线的新手，我需要对此提出建议。

MaxDeliveryCount 是在死信之前可以尝试多少次消息。它似乎等于核心数，但它不应该。可能只是巧合。

MessageLockDuration 仅在您使用PeekLock 接收模式时才有意义。对于ReceiveAndDelete 来说没关系。

至于并发，即使你的工作是 CPU 密集型的，如果更高的并发是可能的，我会进行基准测试。

要查看的消息接收器上的另一个参数是PrefetchCount。它可以通过减少与代理的往返次数来提高整体性能。

还有一个疑问是，让我们假设侦听器并行执行了 4 个作业并开始执行。一个作业完成了它的执行并变成了完成状态。因此侦听器将立即选择下一项或等待所有 4 个作业完成 (MaxConcurrentCalls: 4)。

当您的并发设置为 4 并且已完成一条消息处理时，侦听器将立即开始处理第 5 条消息。

另外，现在，监听器接收到的项目数量是不按顺序排列的。我想维护它的创建顺序。

要按发送顺序处理消息，您需要使用sessions 发送和接收消息。

我的要求是最高性能。由 windows 服务完成的工作是一个 CPU 密集型任务，这就是为什么我限制为 4，因为系统是 4 核。

有很多事情需要考虑。 Windows 服务位置的位置会影响延迟和消息吞吐量。横向扩展可能会有所帮助，等等。