Я был бы признателен, если бы кто-нибудь мог указать мне в направлении некоторых разумных масштабных цифр / ограничений на rabbitmq (на «среднем» оборудовании, fwiw) или поделиться своим опытом с его производительностью. Я пытаюсь получить представление о количестве очередей, количестве подписчиков в очередях, влиянии на производительность сотен или тысяч прослушивателей в очередях разветвления, любых жестких числах, которые могут возникнуть у кролика в среде с высокой пропускной способностью.
performance
rabbitmq
user21640
источник
источник
Ответы:
Прежде всего, вам необходимо понять, какие элементы в вашем списке имеют пределы масштабирования, которые вы можете использовать, а какие нет. Отчасти это зависит от реализации, поэтому помогает прочитать о внутренностях, например, книге RabbitMQ in Action.
Количество очередей ограничено вашей оперативной памятью. Количество сообщений в игре, с другой стороны, не ограничивается оперативной памятью, поскольку RabbitMQ автоматически выводит их на диск. Однажды я случайно получил почти 8 миллионов сообщений на сервере разработки, когда не обращал на это внимания.
Также нет ограничений на размеры сообщений, но вы действительно должны подумать дважды, если размер одного сообщения превышает 512 КБ. В итоге я использовал кэш-память для передачи больших объектов между приложениями и отправлял только более мелкие управляющие сообщения, содержащие ключ memcache. Но если вы действительно хотите, вы можете отправлять огромные JPEG и двоичные объекты, такие как JAR-файлы, в качестве сообщений.
Количество подписчиков - это ограничение ОС, поскольку подписчику требуется открыть хотя бы один сокет TCP. Конечно, это настраивается в большинстве операционных систем, поэтому ваш пробег будет разным, и поэтому вы должны протестировать свою модель. Я использовал JMETER для нагрузочного тестирования наших веб-приложений, и я только что обнаружил этот плагин AMQP https://github.com/jlavallee/JMeter-Rabbit-AMQP, но еще не использовал его. В любом случае, это тот тип тестирования, который быстро подскажет, что будет разумно обрабатывать ваше оборудование (или конфигурация виртуальной машины).
Единственное трудное, что у вас есть, это тестирование большого количества потребителей в очередях разветвления. Возможно, вы также захотите сравнить, используя вместо этого обмен темами, при этом потребители подписываются, используя подстановочный ключ (*), который достигает того же конечного результата. Попробуйте запустить этот тест на как можно большем количестве разных компьютеров, чтобы убедиться, что вы не столкнетесь с каким-либо узким местом, вызванным одним сервером, выполняющим процессы потребителя. PS плагин Jmeter выглядит так, как будто он также может быть полезен для симуляции потребителей.
источник
Это на самом деле не вопрос, требующий ответа - слишком много факторов (скользящее определение «среднего» оборудования, размер сообщений в очереди, количество потребителей и как часто они опрашивают / как быстро они завершают работу в сообщениях и т. Д.). .). Вы действительно должны сравнить свою среду.
Тем не менее, посмотрите некоторые из этих обсуждений производительности RabbitMQ (включая некоторые идеи о том, как вы можете сравнить свою установку, чтобы увидеть, чего вы можете ожидать от Rabbit):
источник