NServiceBus Pub/Sub Distributor/Worker Scenario Too Slow

Question

Я работаю над доказательством реализации концепции NServiceBus v4.x для работы.

Сейчас у меня есть два подписчика и один издатель.

Издатель может публиковать более 500 сообщений в секунду. Он отлично работает.

Подписчик A работает без дистрибьюторов/работников. Это единый процесс.

Подписчик B работает с одним дистрибьютором, питающим N количество рабочих.

В моем тесте я попал в конечную точку, которая создает и публикует 100 000 сообщений. Я это публикую с подписчиками вне очереди.

Подписчик A обрабатывает 100 сообщений в секунду. Абонент B с 2+ работниками (тот же результат с 2, 3 или 4) борется с 50 сообщениями в секунду, валовыми для всех работников.

По моему сценарию, работники (которые я увеличил до 40 потоков на одного работника) ждут, когда дистрибьютор даст им работу.

Я пропустил что-то, что может вызвать дросселирование дистрибьютора? Все автобусы имеют неограниченную лицензию Dev.

Информация о системе: Intel Core i5 M520 @ 2,40 ГГц 8 Гб оперативной памяти SSD жесткого диска

UPDATE 08/06/2013: Я закончил развертывание системы на множество серверов. Я испытываю те же результаты. Каждый сервер с рабочим, который я добавляю, снижает производительность подписчика.

Подписчик B имеет дистрибьютора на одном сервере и два дополнительных сервера для рабочих. С подписчиком B и одним сервером с активным работником я испытываю ~ 80 сообщений/событий в секунду. Добавление другого рабочего на дополнительный физический аппарат уменьшает значение до 50 сообщений в секунду. Кроме того, это «фиктивные сообщения». Никакой логики не происходит в обработчиках, кроме журнала сообщения через log4net. Отключение регистрации не увеличивает производительность.

Предложения?

Answer 1

Если вы масштабируете узлы master/worker NServiceBus на одном сервере, тогда попытка измерения производительности не имеет смысла. Один процесс с несколькими потоками всегда будет лучше, чем дистрибьютор и несколько рабочих узлов на той же машине, потому что дистрибьютор станет узким местом, пока все конкурирует за одни и те же вычислительные ресурсы.

Если рабочие перемещаются на отдельные серверы, это становится совершенно другой историей. Дистрибьютор очень эффективен при рассылке сообщений, если это единственное, что происходит на сервере.

Попробуйте использовать несколько серверов и посмотрите, что произойдет.

Answer 2

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

Если у вас есть poc для нескольких серверов, попробуйте пометить сообщения как «Экспресс», которые не выполняют транзакционную запись в очереди и отключить MSDTC на экземпляре шины, чтобы увидеть, какая производительность возможна без транзакций , Это не подходит для производства, если вы не знаете, где это не является обязательным, или то, что возможно, когда у вас есть архитектура, которая не требует кода DTC.

Answer 3

Вместо того, чтобы иметь обработчик пустышки, который ничего не делает, смогите ли вы имитировать фактическую обработку, добавив некоторое время сна, скажем, 5 секунд. А затем сравните результаты с подписчиком и через дистрибьютора?

Масштабирование (с дистрибутором или без него) полезно только тогда, когда работа, выполняемая одной машиной, занимает много времени, и поэтому помогает больше вычислительных ресурсов. Чтобы помочь в этом, контролируйте счетчик производительности CriticalTime на конечной точке и, когда у вас есть такая потребность, добавьте дистрибьютора. Масштабирование с помощью дистрибьютора при необходимости упрощается, не изменяя код, просто начиная ту же конечную точку в профилях дистрибьютора и работника.