我正在使用Azure.Messaging.ServiceBus SDK，我无法理解下面的语句。
我的订阅有200条消息。我的理解是，如果我执行下面的语句，它必须返回我5个消息计数，或者如果我给值为200，它必须返回我200，但无论我做什么，它始终只返回我一个。我也尝试将TimeSpan设置为非常高的值。基本上，我正在尝试增加接收的吞吐量。我对使用批处理的发送吞吐量很满意，但我想我没有很好地理解SDK来利用最大接收吞吐量。
var messages = await receiver.ReceiveMessagesAsync(5, TimeSpan.FromDays(1));
我是开放的输入改进使用"processorClient.CreateProcessor"了。在这种情况下，除了增加"PrefetchCount">
之外，我看不到任何其他方法。我的理解是，如果我执行下面的语句，它必须返回我5个消息计数，或者如果我给值为200，它必须返回我200
这是不正确的。该参数称为maxMessages，表示将接收的最大消息数，而不是保证。接收消息时没有最小批处理大小。
接收器让服务知道它想要的最大消息数，然后将该操作返回的消息集提供给应用程序。客户端不尝试跨多个操作构建请求大小的批处理。
采用这种方法有两个主要原因。首先，与消息相关联的锁只在有限的时间内持有，之后如果不更新就会过期。如果客户机在多个操作之间保持消息以尝试构建批处理，那么应用程序处理消息的时间将是零星的，在最坏的情况下，您将收到带有过期锁的消息，无法完成。其次，客户端优先考虑尽可能快地向应用程序提供数据，以帮助最大限度地提高吞吐量。
我愿意接受使用"processorClient.CreateProcessor"改进的输入了。在这种情况下，除了增加"PrefetchCount">
之外，我看不到任何其他方法。
吞吐量受到来自网络、主机、工作负载、消息大小/组成和服务层的许多因素的影响。概括建议是很困难的。
一些通常会有帮助的事情:
-
确保您的应用程序在与您的服务总线名称空间相同的Azure区域中运行。
-
考虑增加并发性。这可能涉及到使用多个接收器和/或调优处理器上的并发设置。
-
考虑使用
prefetch来急切地传输来自服务的消息。
(注意:预取中的消息是锁定的，这些锁定不能更新。相应地调整并彻底测试)
我建议阅读使用服务总线消息传递提高性能的最佳实践，因为它涉及到相当多的深度。