Azure 服务总线队列性能

Question

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

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

此外，现在，听众接收的项目数量不正常。 我想维护一个创建它的顺序。 我的要求是最大的性能。 由 Windows 服务完成的工作是一项 CPU 密集型任务，这就是为什么我限制为 4，因为系统是 4 核。

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

还有一个疑问是，让我们考虑侦听器并行获得 4 个作业并开始执行。 一项作业完成执行并成为已完成状态。 因此侦听器将立即选择下一个项目或等待所有 4 个作业完成 (MaxConcurrentCalls: 4)。

Answer 1

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

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

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

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

MessageLockDuration只有在您使用PeekLock接收模式时才重要。 对于ReceiveAndDelete没有关系。

至于并发性，即使您的工作受 CPU 限制，我也会对是否有可能实现更高的并发性进行基准测试。

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

还有一个疑问是，让我们考虑侦听器并行获得 4 个作业并开始执行。 一项作业完成执行并成为已完成状态。 因此侦听器将立即选择下一个项目或等待所有 4 个作业完成 (MaxConcurrentCalls: 4)。

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

此外，现在，听众接收的项目数量不正常。 我想维护一个创建它的顺序。

要按照消息发送的顺序处理消息，您需要使用会话来发送和接收消息。

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

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