RabbitMQ в качестве Message Broker, используемого Spring Websocket, умирает под нагрузкой

Question

Я разрабатываю приложение, в котором нам нужно обрабатывать 160 тыс. Одновременных пользователей, которые подключены к бэкэнду через websocket соединение.

Мы решили использовать реализацию spring websocket и RabbitMQ в качестве посредника сообщений.

В нашем приложении каждый пользователь должен подписаться на свою очередь /exchange/amq.direct/update, а также на другую очередь, где другие пользователи могут потенциально подписаться на /topic/someUniqueName.

В нашем первом тесте производительностимы применили наивный подход, при котором каждый пользователь подписывается на две новые очереди.

При выполнении теста RabbitMQ молча умирает, когда одновременно подключено около 800 пользователей, поэтому активно около 1600 очередей (Смотрите график всех объектов RabbitMQ здесь ).

Я читал, однако, что вы должны быть осторожны, открывая множество соединений с RabbitMQ .

Теперь мне интересно, ожидается ли подход , который ожидается Spring Websocket с открытием одногоочередь на пользователя является концептуальной проблемой для систем с высокой нагрузкой или если в моей системе есть другая ошибка.

Answer 1

Я нашел проблему.Я на самом деле неправильно настроил сервис RabbitMQ и просто дал ему ограничение в 1024 дескриптора файла.Увеличение его решило проблему.

Answer 2

Ограничивающими факторами для RabbitMQ обычно являются:

• память (может быть проверена на панели инструментов), которая должна увеличиваться с количеством сообщений и количеством очередей (если вы не используете отложенные очереди, которые идутнепосредственно на диск).
• максимальное количество файловых дескрипторов (не менее 1 на соединение), для которых по умолчанию часто используются слишком низкие значения (ref: https://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-April/019615.html)
• CPU для маршрутизации сообщений