Masstransit rabbitMQ публикация на многие темы

Question

У меня есть приложение, которое закручивает много потоков. Каждый поток передает один и тот же тип сообщения через masstransit/rabbitmq. Я создал синглтон для хранения одного экземпляра IBus. Приложение публикует только сообщения, поэтому конечные точки не находятся в конфигурации.

Является ли единичный автобус сообщений правильной вещью, которую нужно делать только при публикации? Я провел тестирование производительности, настроив цикл, чтобы постоянно публиковать сообщение. При запуске всего одного потока 52000 сообщений, добавленных в очередь за 60 секунд. Когда выполняется 5 потоков, каждый из которых выполняет один и тот же цикл, всего 8000 сообщений, добавленных в очередь за 60 секунд.

Почему при запуске 5 потоков производительность намного хуже? Должен ли каждый поток иметь свой собственный экземпляр шины?

Answer 1

Один экземпляр шины создает одно соединение с RabbitMQ. И этого обычно достаточно для большинства ситуаций. Если вы хотите уменьшить масштабы соединений, в настоящее время необходимо создать дополнительные экземпляры шины.

Однако вы должны иметь возможность публикации с довольно высокой скоростью, особенно если у вас есть несколько потоков, которые прекрасно сочетаются с TPL (Task Parallel Library). Вы можете также объединить несколько вызовов Publish в один Task.WhenAll(), чтобы избежать латентности между каждым сообщением.

Хорошим испытанием является использование проекта MassTransit-Benchmark, чтобы получить представление о пропускной способности вашего брокера. Обычно я вижу где угодно от 8000-12000 сообщений в секунду, опубликованных и потребляемых через RabbitMQ (не долговечный, с отключенным издателем). Добавление долговечности и подтверждение может замедлить однопоточную публикацию, но не должно сильно влиять на несколько потоков источников. Длительная запись на диск может замедлить работу.

Мне будет интересно узнать, какой код вы использовали, когда несколько потоков были медленнее. Я считаю, что лучше использовать Task.Run(), а не Thread.Create() (или что бы ни был синтаксис сейчас, я больше никогда не использую потоки).