AzureServiceBusReadPerformance我正在尝试使用AzureServiceBus来提高Windows服务的吞吐量。我注意到的是，如果我有这样的代码。client.OnMessageAsync(asyncmessage=>{vartimer=newStopwatch();timer.Start();boolshouldAbandon=false;try{//异步处理消息awaitmessageProcessor.ProcessAsync(message);Interlocked.Increment(refSimpleCounter);//如果处理成功则完成();messageTimes.Add(timer.ElapsedMilliseconds);},选项);选项在哪里OnMessageOptionsoptions=newOnMessageOptions{MaxConcurrentCalls=maxConcurrent,AutoComplete=false};增加MaxConcurrentCalls在一定数量后几乎没有影响（12-16通常用于我正在做的事情）。但是，使用相同的MaxConcurrentCalls创建多个客户端(QueueClient)确实可以提高性能（几乎是线性的）。所以我一直在做的是让#queueclient和maxconcurrentcalls可配置，但我想知道拥有多个队列客户端是否是最好的方法。所以我的问题是：对于windows服务和azure服务总线，使用多个队列客户端进行消息泵送是不好的还是好的做法？我知道它现在已经过时了-但我想我会贡献我的发现。我只看到通过在同一台机器上运行多个进程来提高队列处理性能。就我而言，我使用的是控制台应用程序，但原理是一样的。我认为这最终是因为MaxConcurrency值最终控制了服务总线传递给消费客户端的消息数量-当它达到该限制时，它会在尝试推送更多消息之前有效地进入休眠状态一段时间（根据我的经验大约为1秒）.因此，如果您有一个非常简单的消息处理程序，即使您将MaxConcurrency设置为逻辑核心数量的2x/3x/4x，您也极不可能达到容量，但如果您推送的消息多于处理多个消息，它仍然会对于配置为立即处理的客户端来说非常慢。运行具有相同MaxConcurrency的另一个进程可为您提供两倍的可用容量-即使在同一台机器上-但它实际上并没有为您提供更多功能。最终，正确的配置将取决于排队任务的处理器使用情况。如果它们长时间运行并且倾向于消耗处理器周期，那么MaxConcurrency太大可能会让你失望，而不是向上-扩展到其他机器确实是唯一的解决方案。然而，如果你的队列任务是“瘦”的并且大部分时间都在等待，你将能够获得比处理器中的逻辑核心更高的MaxConcurrency-因为它们不会一直都很忙。以上就是C#学习教程：AzureServiceBus读取性能分享的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权请点击右侧联系管理员删除。如需转载请注明出处：
