我正在使用Azure服务总线队列来满足我的要求之一。要求很简单,azure函数将充当API并在队列中创建多个作业。该功能是可扩展的,并且可以按需创建新实例。微服务创建的作业将由Windows服务处理。因此,发送方是Azure功能,而接收方是Windows服务。由于azure函数具有可伸缩性,因此将有多个函数可以并行执行。因此,被创建到队列中的作业数量将是并行的,每500MS中可能会有一个作业。 Windows服务是一个实例,它是一个队列侦听器,它侦听此队列并并行执行。因此,发送方的数量可能更多,接收方是一个实例。而且必须限制每个并行运行的作业(4,因为这需要更多时间和CPU)。现在,我将Aure Service Bus Queue与以下配置一起使用。我怀疑哪种配置可以满足此特定需求的最佳性能。
对我来说,删除队列中的Job不会成为问题。因此,我可以使用Delete代替Peek-Lock吗?
此外,现在,侦听器接收到的项目数不正确。我想维护创建它的顺序。我的要求是最大的性能。 Windows服务完成了这项工作,这是一项占用大量CPU的任务,因此,由于系统是4核,所以我限制为4。
最大传递计数:4,消息锁定持续时间:5分钟,MaxConcurrentCalls:4(在侦听器中)。我是服务公交的新手,对此我需要个建议。
另一个疑问是,让我们考虑侦听器并行获得4个作业并开始执行。一项工作完成了执行并成为完成状态。因此,侦听器将立即选择下一项或等待所有4个作业完成(MaxConcurrentCalls:4个)。
答案 0 :(得分:1)
对我来说,删除队列中的Job不会成为问题。因此,我可以使用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服务位置的位置可能会影响延迟和消息吞吐量。向外扩展可能会有所帮助,等等。