Производительность RabbitMQ?

[Денис Захаров]

Добрый день,

Разрабатывается высоконагруженная система.

Разбивается на модули (модуль блогов, модуль альбомов, ...).

Модули между собой обмениваются сообщениями.

В качестве транспорта между модулями выбран RabbitMQ.

Часто возникает вопрос, с какой нагрузкой справится кролик? Имеются ли какие-нить тесты/обзоры и т.п. по производительности, а так же опыт кластеризации транспорта?

Буду благодарен за любую информацию в этом направлении.

--

С уважением, Денис

[Alexandre Kalendarev]

Разрабатывается высоконагруженная система.

Разбивается на модули (модуль блогов, модуль альбомов, ...).

Модули между собой обмениваются сообщениями.

В качестве транспорта между модулями выбран RabbitMQ.

Часто возникает вопрос, с какой нагрузкой справится кролик? Имеются ли какие-нить тесты/обзоры и т.п. по производительности, а так же опыт кластеризации транспорта?

а какая предполагается ?

Вот что заявляют разработчики:

So in our test, each datagram contained 16 OPRA messages, and was
sent as one 256 byte AMQP message.

So the throughput can also be seen as:

1. Ingress of 80,000 AMQP messages per second (256b per message)
2. Replicated out to four clients at once (unicast pub/sub)
3. So simultaneously, egress of 320,000 AMQP messages per second (256b
per message)

I.e the real load is about 400,000 mps.

При кластеризации столкнулся с такой проблемой, что кол-во подписок ограничено на одну ноду (10 000). Это регулируется каким-то параметром эрланг машины.  Потом это оказалось нам не нужно.

а какой используется клиент?

Александр

 

[Max Lapshin]

А как мне отписаться от рассылки? Я пытался найти где это сделать, но не нашел.

[Alex Ott]

mailto:rabbitmq_rus...@googlegroups.com

во всех списках рассылки инструкции приведены в заголовках

--
With best wishes, Alex Ott, MBA
http://alexott.blogspot.com/ http://alexott.net/
http://alexott-ru.blogspot.com/
Skype: alex.ott

[Денис Захаров]

Добрый день,

Проект реализуется на python (pylons).

Аудитория для проекта (уже имеется, будет перекинута с других) - несколько миллионов человек.

Перекидываться будет частями, что бы выявлять узкие места и дорабатывать систему.

Нагрузка - вот тут только теория, т.к. число одновременных пользователей под вопросом.

1. Реализация с учетом минимизации сообщений через кролика - прядка 4-8 тысяч в секунду.
2. При попытке свалить на него весь обмен между модулями - 40-80 тысяч в секунду.

Повторюсь - это теория ).

При этом 10% обмена это запросы требующие синхронного ответа. В данный момент это реализовано так:

1. Модуль-инициатор создает временную очередь для ответа.
2. В запрос целевому модулю помещается имя этой очереди.
3. Целевой модуль выполняет необходимые действия и помещает ответ во временную очередь.
4. Модуль-инициатор извлекает ответ и уничтожает очередь.

Отрабатывает эта цепочка на два порядка медленней чем запрос без ответа. Возможно есть другой механизм/подход к решению этой задачи?

Как часто стоит опрашивать модулям свои очереди?

Какие-нить рекомендации из Вашего опыта высоконагруженных систем?

--

С уважением, Денис

16 августа 2010 г. 16:47 пользователь Alexandre Kalendarev <aka...@gmail.com> написал:

[Alexandre Kalendarev]

Денис,

 

Спасибо за содержательный ответ.

если можно в личку более подробно об архитектуре:

почему именно кролик был выбран, какие типы очередей используются, какие решаются задачи с использовнием очередей.

Проект реализуется на python (pylons).

Аудитория для проекта (уже имеется, будет перекинута с других) - несколько миллионов человек.

Перекидываться будет частями, что бы выявлять узкие места и дорабатывать систему.

Нагрузка - вот тут только теория, т.к. число одновременных пользователей под вопросом.

1. Реализация с учетом минимизации сообщений через кролика - прядка 4-8 тысяч в секунду.
2. При попытке свалить на него весь обмен между модулями - 40-80 тысяч в секунду.

Повторюсь - это теория ).

При этом 10% обмена это запросы требующие синхронного ответа. В данный момент это реализовано так:

1. Модуль-инициатор создает временную очередь для ответа.
2. В запрос целевому модулю помещается имя этой очереди.
3. Целевой модуль выполняет необходимые действия и помещает ответ во временную очередь.
4. Модуль-инициатор извлекает ответ и уничтожает очередь.

Отрабатывает эта цепочка на два порядка медленней чем запрос без ответа. Возможно есть другой механизм/подход к решению этой задачи?

 

 

как вариант можно использовать синхронную обработку методом Basic.Consume - тогда обработка будет сразу непосредственно по приходу сообщения. Метод Consume работает быстрее, чем Basic.GET (и сетевой трафик меньше)

 

Как часто стоит опрашивать модулям свои очереди?

 

думаю - это подбирается экспериментально, по мере загрузки сервера. Можно сделать динамическую систему опрос, например опрашивать каждую сек, если кол-во эл-тов очереди увеличивается по сравнению с предыдущим, то время опроса сократить в двое и наоборот. Лично возможности библиотеки питона я не знаю, но в ответе на метод GET : Basic.Get-Ok есть поле count - оставшееся кол-во эл-тов в очереди. (по крайней мере в PHP & librabbitcpp эту возможность я использую). Отдельный запрос на оставшееся кол-во элементов очереди делать не надо. 

 

 

Александр