Rabbitmq - Разумные ожидания производительности / масштаба

13

Я был бы признателен, если бы кто-нибудь мог указать мне в направлении некоторых разумных масштабных цифр / ограничений на rabbitmq (на «среднем» оборудовании, fwiw) или поделиться своим опытом с его производительностью. Я пытаюсь получить представление о количестве очередей, количестве подписчиков в очередях, влиянии на производительность сотен или тысяч прослушивателей в очередях разветвления, любых жестких числах, которые могут возникнуть у кролика в среде с высокой пропускной способностью.

performance rabbitmq

— user21640
источник

Это очень просто проверить, особенно если учесть, что с ожидаемыми цифрами у вас есть бюджет для подготовки некоторых виртуальных машин. Я настоятельно рекомендую вам протестировать его на основе вашего конкретного случая использования, на оборудовании, которое вы ожидаете использовать.

— Андрей М.

Посмотрите на планы CloudAMQP - это проверенные показатели производительности для определенных конфигураций оборудования.

— Восстановить Монику - М. Шредер

11

Прежде всего, вам необходимо понять, какие элементы в вашем списке имеют пределы масштабирования, которые вы можете использовать, а какие нет. Отчасти это зависит от реализации, поэтому помогает прочитать о внутренностях, например, книге RabbitMQ in Action.

Количество очередей ограничено вашей оперативной памятью. Количество сообщений в игре, с другой стороны, не ограничивается оперативной памятью, поскольку RabbitMQ автоматически выводит их на диск. Однажды я случайно получил почти 8 миллионов сообщений на сервере разработки, когда не обращал на это внимания.

Также нет ограничений на размеры сообщений, но вы действительно должны подумать дважды, если размер одного сообщения превышает 512 КБ. В итоге я использовал кэш-память для передачи больших объектов между приложениями и отправлял только более мелкие управляющие сообщения, содержащие ключ memcache. Но если вы действительно хотите, вы можете отправлять огромные JPEG и двоичные объекты, такие как JAR-файлы, в качестве сообщений.

Количество подписчиков - это ограничение ОС, поскольку подписчику требуется открыть хотя бы один сокет TCP. Конечно, это настраивается в большинстве операционных систем, поэтому ваш пробег будет разным, и поэтому вы должны протестировать свою модель. Я использовал JMETER для нагрузочного тестирования наших веб-приложений, и я только что обнаружил этот плагин AMQP https://github.com/jlavallee/JMeter-Rabbit-AMQP, но еще не использовал его. В любом случае, это тот тип тестирования, который быстро подскажет, что будет разумно обрабатывать ваше оборудование (или конфигурация виртуальной машины).

Единственное трудное, что у вас есть, это тестирование большого количества потребителей в очередях разветвления. Возможно, вы также захотите сравнить, используя вместо этого обмен темами, при этом потребители подписываются, используя подстановочный ключ (*), который достигает того же конечного результата. Попробуйте запустить этот тест на как можно большем количестве разных компьютеров, чтобы убедиться, что вы не столкнетесь с каким-либо узким местом, вызванным одним сервером, выполняющим процессы потребителя. PS плагин Jmeter выглядит так, как будто он также может быть полезен для симуляции потребителей.

— Майкл Диллон
источник

6

Это на самом деле не вопрос, требующий ответа - слишком много факторов (скользящее определение «среднего» оборудования, размер сообщений в очереди, количество потребителей и как часто они опрашивают / как быстро они завершают работу в сообщениях и т. Д.). .). Вы действительно должны сравнить свою среду.

Тем не менее, посмотрите некоторые из этих обсуждений производительности RabbitMQ (включая некоторые идеи о том, как вы можете сравнить свою установку, чтобы увидеть, чего вы можете ожидать от Rabbit):

— voretaq7
источник

1

Я знаю о многих переменных. Вот почему я упоминал такие вещи, как «среднее» оборудование, в кавычках, поскольку я понимаю, насколько неясна эта идея. Тем не менее, я думал, что некоторые цифры, полученные из опыта людей, будут полезны. Спасибо за ссылки.

— user21640

1

@ user21640 Это не просто аппаратное обеспечение, которое добавляет неясности в ваш вопрос - высокочастотная торговля может иметь другое представление о «высокой емкости», чем вы или я, и совершенно разные определения приемлемой производительности. В конечном счете, единственный человек , чей опыт вопросов вы, в вашей среде, и в моем опыте один хорошо спланированный местный ориентир стоит тысячи внешних отчетов , когда дело доходит до уверенности в планировании емкости - вы никогда не знаете , когда ваша нагрузка патологического случай: -)

— voretaq7