Почему низкая скорость публикации сообщений в очередь RabbitMQ?

Question

[alexartamonov]

Добрый день

При одиночной отправки сообщений в RabbitMQ скорость не поднимается выше 20-25 сообщений в секунду.
Если использовать пакетную отправку - все быстро (30к сообщений в секунду легко принимает).
В чем может быть причина?

Comments

[Александр]

та же самая проблема

[Everything_is_not_so_bad]

alexartamonov Александр
Ошибка в 17-й строке.

Answer 1

[Сергей]

Всё зависит от того какие параметры отказоустойчивости применяются. В RabbitMQ работа одного канала (channel) синхронна, нет параллельной обработки команд. Если есть ожидание подтверждения от сервера и требование записи данных на диск (а RabbitMQ, если ничего не изменилось за последние годы, аггрегирует запись в батчи, чтобы уменишить кол-во IOPS на диск, то есть какое-то ожидание), то это увеличивает временя одной команды. Плюс сетевое RTT.
Если надо посылать как можно больше - открывайте много каналов. Ради интереса попробуйте потестировать на простой очереди в памяти (это должно уменьшить время обработки одной команды).

Comments

[Александр]

то есть это норма что скорость 25 комманд в секунду? Если мы делаем пуш_батч то он и 30к в секунду пишет, проблема именно в одиночных записях

[Сергей]

AMQP протокол нацелен больше на целостность данных, чем на возможность закинуть как можно больше сообщений одному отправителю. Если нужны гарантии - нужно подождать. Но как я написал выше, никто не мешает даже одному отправителю открыть несколько каналов по верх одного tcp подключения (по сути похоже на http/2).

[Everything_is_not_so_bad]

Если надо посылать как можно больше - открывайте много каналов.

Слишком много не нужно, лучше использовать менеджер с пулом каналов.

[Сергей]

Слишком много не нужно, лучше использовать менеджер с пулом каналов.

Дополню немного. Да, хорошо держать пул, само открытие/закрытие канала тоже требует взаимодействие по сети. Но с точки зрения RabbitMQ канал это недорогой ресурс (Erlang процесс), поэтому если есть не так много клиентов, то даже 1000 каналов на каждом не должно скушать много ресурсов на сервере. Также канал позволит масштабироваться по всем ядрам процессора отпрвителю (процесс маршрутизации сообщений как раз происходит в рамках канала).

Answer 2

[mayton2019]

Вопрос - странный. Ну если вам нужно быстро - то отправляйте батчем. Собственно - это такой общий паттерн который можно рекомендовать всегда. Как - советовать носить шерстяные штаны зимой.

Почему медленно когда по 1 сообщению? Идей много. Как вариант - виновата сетевая латентность и некие усиленные проверки транзакций или квитирований с вашей стороны. Вот по этому пункту нужно смотреть конфигурации и пинговать и трассировать ваши сети.

Answer 3

[Dimonchik]

ну так надо тюнить, что ж вы на тостере сидите-то?

https://blog.rabbitmq.com/posts/2012/04/rabbitmq-p...
https://www.rabbitmq.com/runtime.html
https://blog.rabbitmq.com/posts/2012/04/rabbitmq-p...

Comments

[alexartamonov]

Да, настройки из коробки, но пакетно же добавляет по 30к в секунду

[Александр]

Проблем с производтельностью я думаю нет. Пакетно 30к в секунду свободно принимает. Проблема с basic_publish именно когда по 1 мессаге в цикле шлет, больше 25в секунду скорость не поднимается, соответственно и скрипт который это делает выполняется долго

Answer 4

[Everything_is_not_so_bad]

Вообще, AMQP - непростой протокол и в нам есть много взаимодействий по сети. У разных реализаций протокола могут быть разные особенности, даже в пределах того же языка программирования.
Если отправка по интернету, то вообще все может быть менее предсказуемо и соединения могут отваливаться спонтанно, что может приводить к "заморозке" или частым переподключениям.
Не предоставлено никакой информации об:
используемых версиях библиотек и RabbitMQ, рантайма, конфигураций сети, ... как и самого кода.