Azure服务总线读取性能

Question

我正在使用Azure Service Bus尝试提高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
            };

在某个特定数量（通常为12-16）之后，增加MaxConcurrentCalls的效果很小。

但是，使用相同的MaxConcurrentCalls创建多个客户端（QueueClient）确实可以提高性能（几乎是线性的）。

因此，我一直在做的是使#queueclient和maxconcurrentcalls可配置，但我想知道是否使用多个queueclients是最佳方法。

所以我的问题是：对于Windows服务和Azure服务总线，使用多个具有消息泵的queueclients是好还是坏的做法？

- Josh

---

你的服务器有多少个核心？你所有的Windows服务实例都将在同一台服务器上运行吗？否则，创建多个工作进程而不是多个线程来增加队列吞吐量并不是一个坏的做法。扩展总是一个解决方案^^ - Thomas

4核心。最初的目标是每个服务器单个实例（总共5-7台服务器）。我希望从单个实例中获得最大的效益（我相信我可以安装多个实例并获得类似的结果）。 - Josh

Answer 1

我知道这已经很旧了，但我想贡献我的发现。

在同一台机器上运行多个进程可以提高队列处理性能。在我的情况下，我使用控制台应用程序，但原理是相同的。

我认为，这主要是因为MaxConcurrency值最终控制着服务总线将交给消费客户端的消息数量。当达到该限制时，它会在一段时间内（大约1秒钟）进入休眠状态，然后尝试推送更多的消息。

因此，如果您有一个非常简单的消息处理程序，即使将MaxConcurrency设置为逻辑核心数的2倍/3倍/4倍，您也极不可能达到容量，但是如果推送的消息超过客户端一次处理的配置，则多个消息的处理仍然会非常缓慢。在具有相同MaxConcurrency的另一个进程上运行将使您获得两倍的可用容量，即使在同一台机器上，但实际上并没有增加任何功率。

最终，正确的配置将取决于您的队列任务处理器使用率的情况。如果它们运行时间很长且 tend to chew through processor cycles，则 MaxConcurrency 过大可能会使你的速度变慢，而不是加快速度。扩展到其他机器真的将是唯一的解决方案。

然而，如果您的队列任务很“稀疏”并且大部分时间都在等待，则比处理器的逻辑核心更高的 MaxConcurrency 可能会被接受，因为它们并不总是繁忙的。

- Andras Zoltan