RabbitMQ о проблемах производительности EC2

Question

Какими могут быть ожидания производительности RabbitMQ на EC2? Буду признателен за обмен опытом здесь.

Я пытаюсь провести тест производительности RabbitMQ на aws EC2. У меня есть 3 отдельных экземпляра EC2 для RabbitMQ, Publisher и customer / worker.

Сценарий, который у меня есть, заключается в том, что Publisher толкает строку JSON (приблизительно 165-200 байт) для прямого обмена типами с длительным набором значений, равным true, и связывает очередь с долговременным набором значений, равным true (т.е. оба в постоянном режиме). Потребитель / работник работает на отдельной коробке - продолжает тянуть сообщения. (Ожидается, что продвижение этих сообщений на рабочем месте будет сохранено в MongoDB, и Publisher будет заменен сервисом Restful с использованием REST easy)

Для простоты я смоделировал этот сценарий с помощью примера кода Multicast. Я разделил многоадресный код на два отдельных Java-файла, а именно «Producer» и «Worker», чтобы запускать каждый из них в отдельном окне. Я использовал «c1.mediam» EC2 с 32-битным сервером Ubuntu v11.4 для запуска производителя и потребителя и «m1.large» с 64-битным сервером Ubuntu v11.4 для RabbitMQ.

Я могу достигнуть пропускной способности 3-5k сообщений в секунду, то есть, сохраняя скорость отправки сообщений исследования до 5K. (Это совпадает с http://www.rabbitmq.com/faq.html#performance-latency)

Далее, когда я увеличиваю скорость передачи до 10-12k сообщений в секунду. Потребительская способность потреблять сообщения падает до 1-2 тыс. Сообщений в секунду, и это создает отставание (во многих случаях оно также падает ниже 800 сообщений в секунду).

С вышеописанным сценарием у меня есть следующие вопросы, и я был бы признателен за мысли / предложения, чтобы улучшить пропускную способность потребителя. (ПРИМЕЧАНИЕ. Ожидается, что все сообщения в моем сценарии будут схожего типа, что не даст возможности сгруппировать их для настройки маршрутизации, поэтому может потребоваться некоторый подход с балансировкой нагрузки)

1) Такая производительность наблюдается с одним сервером rabbitMQ, одним обменом и одной очередью. Можно ли что-нибудь еще настроить, настроить для увеличения пропускной способности до 5 Кб в постоянном режиме.

2) Я понимаю, что кластеризация может быть другим вариантом. Однако мне нужно установить кластер на основе входящей нагрузки, и я не могу получить группировку сообщений / идентификацию для определения маршрутизации (так как сообщения, как ожидается, будут просто описанием журнала). Могу ли я иметь кластеризацию после опции балансировки нагрузки для работника / потребителя?

3) Ожидается, что я буду обрабатывать несколько сотен тысяч запросов в секунду. Буду признателен за обмен опытом и подходы для достижения этой цели.

Answer 1

Рассматривали ли вы добавление нескольких потребителей?Это одно из основных преимуществ слабосвязанной архитектуры шины / сообщения по сравнению со строго связанной архитектурой.Это может помочь понять потребность в объеме сообщения.Это эталонный тест только для того, чтобы увидеть, что вы можете сделать, или это связано с реальной потребностью приложения?

Answer 2

Сотни кГц очень и очень высоки: если RabbitMQ вообще может это сделать, вы смотрите на разбиение по кластеризованным узлам. Эти авторы обнаружили, что их экземпляры EC2 могут обрабатывать не более 100K пакетов в секунду, поэтому очевидно, что вы не получите пропускную способность сообщений выше, чем в одном экземпляре.

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

Answer 3

Какой тип хранилища вы используете для экземпляров EC2?Хранилище EBS более надежно, но иногда оно имеет очень низкую пропускную способность (особенно если это том EBS небольшого размера, т. Е. <100 ГБ).Хранилище экземпляров, с другой стороны, имеет гораздо лучшую производительность ввода-вывода (по нашему опыту, по крайней мере), но может «жить» только до тех пор, пока работает экземпляр.Кроме того, большая разница в типе экземпляра, который вы используете.Оба m1.small и c1.medium имеют умеренную производительность ввода-вывода (http://aws.amazon.com/ec2/instance-types/).</p>

. Мы запускаем RabbitMQ в EC2 с сохранением для всех сообщений. Мы используем только экземпляры m1.large (64-битные с высокой производительностью ввода-вывода). Мы началис хранилищем EBS, затем переключенным на хранилище экземпляров, чтобы увидеть, есть ли какое-либо улучшение. И экземпляры хранилища экземпляров быстрее с точки зрения пропускной способности ввода-вывода. Но недостатком является то, что все сохраненные сообщения теряются вместе с завершением / отказомэкземпляр (хотя до сих пор мы никогда не сталкивались с ошибками). В нашем сценарии нам не нужна такая большая пропускная способность, но мы очень заботимся, если наши сообщения теряются: -)

В заключениеВы можете попробовать перейти к настройке хранилища экземпляров, чтобы посмотреть, как это происходит, если есть какие-либо улучшения.И если это работает намного лучше, то я думаю, http://www.rabbitmq.com/pacemaker.html - это решение для преодоления неудачи.По крайней мере, это направление, в которое мы переключаемся.

Приветствия