c# - Azure 服务总线读取性能

Question

我正在尝试使用 Azure 服务总线提高 Windows 服务的吞吐量。我注意到，如果我有这样的代码。

 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)。

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

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

所以我的问题是:对于 Windows 服务和 Azure 服务总线来说，运行多个带有消息泵的队列客户端是坏还是好做法？

Answer 1

我知道这现在已经很老了 - 但我想我应该贡献自己的发现。

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

我认为最终这是因为 MaxConcurrency 值最终控制服务总线将向消费客户端传递多少消息 - 当它达到该限制时，它实际上会进入休眠状态一段时间(根据我的经验，大约 1 秒)，然后再尝试推送更多消息。

因此，如果您有一个非常简单的消息处理程序，即使您将 MaxConcurrency 设置为逻辑核心数的 2x/3x/4x，您也不太可能达到容量，但处理多个消息会如果您推送的消息多于客户端配置为一次处理的消息数量，速度仍然会很慢。使用相同的 MaxConcurrency 运行另一个进程可以为您提供两倍的可用容量 - 即使在同一台计算机上 - 但它实际上并没有提供更多的功能。

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

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