Очередь NServiceBus Timeoutsdispatcher заливается сообщениями во время стресс-тестов

Question

Я делаю некоторые стресс-тесты для саги, которая использует 2 таймаута. Во время теста создается около 21 тыс. Саг. Таким образом, это означало бы тайм-ауты 42K, но я замечаю, что тайм-аут очереди диспетчера саги наводнен 100-тысячными сообщениями до тех пор, пока не произойдет сбой, потому что предел памяти MSMQ поражен.

Я наблюдаю это поведение, так как я переключил механизм персистентности с RavenDB на SQL Server.

Есть ли у кого-нибудь идеи, что может быть неправильным?

Транспорт: MSMQ
послесвечения: NHibernate пакеты, используемые: настройки

NHibernate version 4.0.4.4000 
NServiceBus version 5.2.14 
NServiceBus.Host version 6.0.0 
NServiceBus.Log4Net version 1.0.0 
NServiceBus.NHibernate version 6.2.7 

Тест:
* конечная точка 1 посылает 22000 сообщений конечной точке 2.
* точка 2 хостов сага, которая началась этим сообщением.
* каждая сага публикует событие, а затем запрашивает 2 тайм-аута: 1 через 4 минуты, 1 на 10 минут.

Наблюдаемое поведение:
* Конечная точка 1 отправляет 22 тыс. Сообщений менее чем за минуту.
* Конечная точка 2 (сага) обрабатывает от 5 до 10 сообщений в секунду.
* через 4 минуты запускаются первые таймауты, а конечная точка 2 все еще обрабатывает сообщения из своей очереди и тем самым создает новые экземпляры саги.
* с этого момента очередь тайм-аутов в очереди конечных точек саги заполняется сообщениями.
* после 10 минут или около того тайм-аутдискаторная очередь уже содержит более 170 тыс. Сообщений и по-прежнему заполняется.
* Это продолжается до тех пор, пока не закончится оконечная нагрузка 2, так как предел памяти MSMQ будет удален, или все сообщения из входной очереди будут обработаны. Если последнее встречается первым, счетчик сообщений очереди тайм-аутов начинает уменьшаться до тех пор, пока он не достигнет 0.

Answer 1

Выполнял ли тот же стресс-тест с RavenDB? И SQL Server на машине, более или менее одинаковой, с быстрыми дисками?

Update

Некоторые проверки для вашей саги

• используется ли [Уникальный] атрибут и он используется должным образом? Другими словами, вы используете уникальные идентификаторы для каждого входящего сообщения? Итак, чтобы каждое входящее сообщение, порождающее 2 тайм-аута, создало уникальный экземпляр саги? Если каждое входящее сообщение обращается к одной и той же Саге, это будет большой случай для предельно ограниченной пропускной способности. Представьте, что экземпляр Saga был создан уже один раз, иначе объяснение станет сложным. Итак, Message1 входит, пытается найти строку в базе данных, находит и блокирует ее. Второе сообщение приходит одновременно, находит строку, но она заблокирована. Он повторит попытку. Message3, пока не появится Message100 (если параллелизм установлен равным 100), и все пытаются сделать то же самое, сразу же сбой. Вы можете видеть, что это ограничит пропускную способность на некоторое время :)
• Правильные ли индексы на таблицах Saga и Timeout?
• Каков максимальный уровень параллелизма?

Основываясь на номере сообщения, вы говорите, что вы отправляете 22 тыс. Сообщений, что приводит к сообщениям тайм-аута 44 тыс. Изображение все эти таймауты находятся в MSMQ. Представьте, что сообщения действительно очень маленькие, например, 1Kb. Информация заголовка, добавленная NServiceBus, может занимать 2Kb. Это 44 000 раз 3Kb составляет примерно 135 мегабайт. Таким образом, нет возможности заполнить стандартную установку MSMQ, которая по умолчанию имеет квоту в 1 ГБ.

Это, вероятно, означает, что ваша очередь в очереди заполняется полностью. Find more information on MSMQ connectionstrings и установите соответствующую строку соединения. Например

<connectionStrings> 
    <add name="NServiceBus/Transport" 
    connectionString="deadLetter=false;journal=false;"/> 
</connectionStrings> 

Сообщения с TimeToBeReceived множества атрибутов (link) в конечном итоге в deadletter очереди. Кроме того, очереди очистки заставят все сообщения переходить в очередь очереди. Если вы не установите правильную строку соединения.