Azure服务总线读取性能 [英] Azure service bus read performance

问题描述

我正在尝试使用Azure Service Bus提高Windows服务的吞吐量.我注意到的是，如果我有像这样的代码.

I am trying to improve throughput on a windows service using Azure Service Bus. What I have noticed is that if I have code like like this.

 client.OnMessageAsync(async message =>
            {
                var timer = new Stopwatch();
                timer.Start();
                bool shouldAbandon = false;
                try
                {
                    // asynchronouse processing of messages
                    await messageProcessor.ProcessAsync(message);
                    Interlocked.Increment(ref SimpleCounter);
                    // complete if successful processing
                    await message.CompleteAsync();
                }
                catch (Exception ex)
                {
                    shouldAbandon = true;
                    Console.WriteLine(ex);
                }

                if (shouldAbandon)
                {
                    await message.AbandonAsync();
                }
                timer.Stop();
                messageTimes.Add(timer.ElapsedMilliseconds);
            },
           options);

选项在哪里

OnMessageOptions options = new OnMessageOptions
            {
                MaxConcurrentCalls = maxConcurrent,
                AutoComplete = false
            };

增加MaxConcurrentCalls在达到一定数量后几乎没有效果(通常我的工作为12-16).

Increasing MaxConcurrentCalls has little effect after a certain number (12-16 usually for what I am doing).

但是使用相同的MaxConcurrentCalls创建多个客户端(QueueClient)确实可以提高性能(几乎是线性的).

But creating multiple clients (QueueClient) with the same MaxConcurrentCalls does increase performance (Almost linearly).

所以我一直在做的是使#queueclient和maxconcurrentcalls可配置，但是我想知道是否有多个queueclient是最好的方法.

So what I have been doing is making #queueclient and maxconcurrentcalls configurable but I am wondering if having multiple queueclients is the best approach.

所以我的问题是:是否有多个带有消息泵的队列客户端运行Windows服务和Azure服务总线的不良或良好习惯?

So my question is: Is having multiple queueclients with messagepumps running a bad or good practice for a windows service and azure service bus?

推荐答案

我知道这确实很老了-但我想我会贡献自己的发现.

I know this is really old now - but I thought I'd contribute my own findings.

仅在同一台计算机上运行多个进程，我发现队列处理性能得到了提高.就我而言，我使用的是控制台应用程序，但是原理是相同的.

I'm seeing an increase in queue processing performance just by running multiple processes on the same machine. In my case, I'm using console apps, but the principle is identical.

我认为最终是因为MaxConcurrency值最终控制着服务总线将发送给使用方客户端的消息数量-当达到该限制时，它实际上进入睡眠状态一段时间(大约1秒钟)我的经验)，然后再尝试发送更多消息.

I think ultimately it's because the MaxConcurrency value is ultimately controlling how many messages the Service Bus will hand to a consuming client - when it reaches that limit, it effectively goes to sleep for a period of time (around 1 sec in my experience) before trying to push more messages down.

因此，如果您有一个非常简单的消息处理程序，即使将MaxConcurrency设置为逻辑内核数的2x/3x/4x，也很难达到容量，但是如果满足以下条件，对多条消息的处理仍然非常慢您推送的消息多于客户端配置为立即处理的消息.使用相同的MaxConcurrency运行另一个进程将为您提供两倍的可用容量(即使是在同一台计算机上)，但实际上并没有提供更多的功能.

So if you have a very simple message handler, you're incredibly unlikely to reach capacity even if you set MaxConcurrency to 2x/3x/4x the logical core count, but processing of multiple messages will still be very slow if you push more messages than the client is configured to handle at once. Running another process with the same MaxConcurrency is giving you twice the available capacity - even when on the same machine - but it's not actually giving any more power.

最终，正确的配置将取决于队列任务的处理器使用情况配置文件.如果它们长时间运行并且倾向于消耗处理器周期，那么MaxConcurrency太大可能会使您减速而不是加速-扩展到其他计算机确实是唯一的解决方案.

Ultimately, the right configuration is going to depend on the processor usage profile of your queue tasks. If they are long-running and tend to chew through processor cycles, then having too great a MaxConcurrency likely slow you down, rather than up - and scaling out to other machines really will be the only solution.

但是，如果您的队列任务是稀疏的"并且花费大部分时间在等待，那么您将能够获得比处理器中逻辑内核更高的MaxConcurrency，因为它们不会一直都很忙.

If, however, your queue tasks are 'sparse' and spend most of their time waiting, then you will be able to get away with a higher MaxConcurrency than there are logical cores in your processor - because they won't all be busy all the time.

这篇关于Azure服务总线读取性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！