Azure Проблема производительности шины обслуживания MassTransit

Question

Так что я играл с MassTransit и Azure Service Bus Premium, вот пример одного из моих потребителей. Гипотетическая начальная загрузка для одного издателя будет около 1000 сообщений в секунду. Однако всякий раз, когда я пытаюсь настроить потребителя, он, как правило, в среднем составляет около 20-40 сообщений на л oop.

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>>()));
    });
});

Я попробовал Тест пропускной способности , который обрабатывал более тысячи сообщений в секунду. Кто-нибудь получил какие-нибудь советы о том, как добиться оптимальной производительности? И, может быть, имеет смысл рассмотреть управляемый экземпляр RabbitMq, поскольку его необходимо масштабировать? Такое ощущение, что Azure Service Bus на самом деле не подходит для такой высокой пропускной способности?

Редактировать: Небольшое дополнение к этому, подозреваю, что это связано с требованием сохранять предварительную выборку до 20, а затем - параллелизм потребителей действительно определяет производительность. Таким образом, в основном, это требует конфигурации уровня потребителя с точки зрения предполагаемых требований. Что заставило бы меня больше склоняться к использованию кролика.

Answer 1

Максимальный размер вашего пакета сообщений составляет 500, что, честно говоря, слишком много. Если для параметра MaxConcurrentCalls установлено значение 20, вы всегда будете превышать время ожидания вместо предельного размера пакета, поскольку клиентская библиотека Azure будет доставлять только 20 сообщений одновременно, а размер пакета значительно выше этого значения (500 против 20). Вам нужно установить его достаточно высоко, чтобы он мог завершить пакет, или вы всегда будете выполнять пакет только по таймауту.

Уменьшите размер пакета и увеличьте MaxConncurrentCalls, чтобы они были одинаковыми, или по крайней мере, поэтому размер пакета меньше, чем предел одновременных вызовов, так что пакеты могут быть завершены при получении сообщения вместо ожидания истечения времени ожидания.