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