Azure 服务总线性能问题 MassTransit答案

【问题标题】：Azure Service Bus performance issue MassTransitAzure 服务总线性能问题 MassTransit
【发布时间】：2020-03-30 09:01:26
【问题描述】：

所以我一直在使用 MassTransit 和 Azure Service Bus Premium，这是我的一个消费者的示例。假设一个发布者的初始负载约为每秒 1000 条消息。但是，每当我尝试配置消费者时，似乎平均每个循环大约有 20-40 条消息。

cfg.ReceiveEndpoint("ReceivePoint", e =>{
    e.PrefetchCount = 500;
    e.MaxConcurrentCalls = 20;
    e.Batch<IBlahContract>(b => {
       b.MessageLimit = 500;
       b.TimeLimit = TimeSpan.FromSeconds(1);
       b.Consumer(() => new BatchBlahConsumer(provider.GetRequiredService<IRepository>(), provider.GetRequiredService<ILogger<BatchBlahConsumer>>()));
    });
});

我确实尝试过Throughput test，它每秒管理一千多条消息。有没有人得到任何关于如何实现最佳性能的提示？考虑 RabbitMq 的托管实例是否更有意义，因为这需要扩展？就是感觉 Azure Service Bus 不太适合这么高的吞吐量？

编辑：对此略有补充，怀疑它与将预取保持在 20 左右的要求有关，然后消费者并发才是真正定义性能的因素。所以基本上，就估计需求而言，它需要消费者级别的配置。这会让我更倾向于使用兔子。

【问题讨论】：

标签： azure amqp masstransit servicebus

【解决方案1】：

您的批量消息限制是 500 条，这实在是太高了。将 MaxConcurrentCalls 设置为 20 时，您将始终达到超时而不是批处理大小限制，因为 Azure 客户端库一次只会传送 20 条消息，并且批处理大小明显高于该值（500 对 20） .您需要将其设置得足够高，以便它可以完成批处理，否则您将始终仅在超时时完成批处理。

降低批处理大小，增加 MaxConncurrentCalls，使它们相同，或者至少使批处理大小小于并发调用限制，以便批处理可以在收到消息时完成，而不是等待超时.

【讨论】：

这是有道理的。实际上，从那时起就开始以更高的并发性和更低的预取来使用它。考虑到我们的规模，它似乎仍然在与 1000msgs/s 之类的速度作斗争，因此不确定一个消息单元是否足够。