Comments 17
Крайне занимательное сравнение. Ещё бы сравнить работоспособность Simple Notification Service.
Очень любопытно, почему не рассматривается Azure Service Bus.
XMPP то тут причём?)
И лучше провести сравнение ещё и с zeromq.
И лучше провести сравнение ещё и с zeromq.
практика показала, что на больших очередях rabbitmq начинает всё же медленно обрабатывать сообщение, что приводит в итоге к росту очередей.
Размер очередей должен быть где-то около 300к сообщений, что, конечно, не является общепринятым значением.
Хотя четкого значения очереди выявить всё же не удалось, наверно еще зависит от размера и частоты прихода новых сообщений.
Размер очередей должен быть где-то около 300к сообщений, что, конечно, не является общепринятым значением.
Хотя четкого значения очереди выявить всё же не удалось, наверно еще зависит от размера и частоты прихода новых сообщений.
За кроликом вообще нужно присматривать, благо у него неплохая админка и http api.
У нас однажды была ситуация, когда он начал отказываться принимать новые сообщения из-за небольшого, по его мнению, свободного места на диске :) При этом во всем остальном он работал как положено
У нас однажды была ситуация, когда он начал отказываться принимать новые сообщения из-за небольшого, по его мнению, свободного места на диске :) При этом во всем остальном он работал как положено
ага, главное присматривать, да )
а в целом он хорош, да
а в целом он хорош, да
Ага, есть такая особенность. www.rabbitmq.com/memory.html
By default RabbitMQ will block producers when free disk space drops below 1GB.
В первом тесте я загружал в очередь 1кк сообщений, а потом выгружал. Всё в 5 потоков. Появилялись проблемы и скорость падала, но не критично.
Если у вас размер очереди доходит до 300к сообщений, то может стоит увеличить количество обработчиков?
Если у вас размер очереди доходит до 300к сообщений, то может стоит увеличить количество обработчиков?
Огромным плюсом SQS является нативная интеграция с CloudWatch. Мы можем мониторить размер очереди и наращивать мощности обработчиков в зависимости, например, от её размера. Так же и уменьшать их количество, если очередь «разгребли».
Ну вот, ещё один тест производительности очередей, который ровным счётом ничего не показывает :( Чтобы протестировать производительность, нужно тест держать запущенным хотя бы полчаса. За это время очередь хоть как-то прогреется. Опять же, надо делать минимум два варианта теста: 1. Очередь никогда не растёт, т.к. отправка медленнее получения (ок, в данном случае, достаточно пару минут продержать, и то скорость может варьироваться); 2. Очередь накапливается: набрать хотя бы 300-500к сообщений в очередь, тогда реббит начнёт её записывать на диск и уже можно будет посмотреть производительность в зависимости от диска.
И главное особо думать не надо, всё написано за вас: www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/
И главное особо думать не надо, всё написано за вас: www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/
В первом тесте «ростил» очередь до 1кк сообщений.
И цель была не сравнить производительность очередей, а узнать что можно получить от Rabbit в амазоновском окружении. Стоит ли использовать Rabbit или хватит SQS.
Мне кажется, что держать стабильно 300-500к сообщений в очереди — это плохая практика, очередь плохое место для хранения данных. Такое возможно в исключительных случаях, но этот вариант я и проверил в первом тесте — средняя скорость отдачи не сильно зависит от количества сообщений в очереди.
И цель была не сравнить производительность очередей, а узнать что можно получить от Rabbit в амазоновском окружении. Стоит ли использовать Rabbit или хватит SQS.
Мне кажется, что держать стабильно 300-500к сообщений в очереди — это плохая практика, очередь плохое место для хранения данных. Такое возможно в исключительных случаях, но этот вариант я и проверил в первом тесте — средняя скорость отдачи не сильно зависит от количества сообщений в очереди.
Спасибо за статью, немного покритикую.
Сперва про пакетную обработку — если вы про префетчинг в Rabbit MQ, то его как правило все используют и не гоняют по одному сообщению. Есть неплохая статья про это habrahabr.ru/post/153431/
Насчет того, что в HTTP большую часть времени занимает установка соединения — категорически рекомендую использовать HTTP клиент с поддержкой keep-alive.
Софт для бенчмарка на чем был написан?
Ещё из статьи не понял использовали вы durable очереди RabbitMQ (пишутся на диск) или нет (держатся в памяти)?
Что бы не тратить на каждом сообщении время для установки соединения, авторизации и прочего, RabbitMQ и SQS позволяют обрабатывать сообщения пакетами. Это доступно как для отправки, так и для получения сообщения. Т.к. пакетная обработка по умолчанию отключена и в RabbitMQ и в SQS, мы так же не будем её использовать для сравнения.Что-то вы недостаточно коснулись этого вопроса, либо не до конца вникли…
…
работа идёт по HTTP протоколу и большую часть времени занимает установка соединения
Сперва про пакетную обработку — если вы про префетчинг в Rabbit MQ, то его как правило все используют и не гоняют по одному сообщению. Есть неплохая статья про это habrahabr.ru/post/153431/
Насчет того, что в HTTP большую часть времени занимает установка соединения — категорически рекомендую использовать HTTP клиент с поддержкой keep-alive.
Софт для бенчмарка на чем был написан?
Ещё из статьи не понял использовали вы durable очереди RabbitMQ (пишутся на диск) или нет (держатся в памяти)?
На самом деле все очереди в ребите пишутся на диск, чтобы не забивать память. Разница в том, что:
1. Durable — не отпускает вас, пока не запишет сообщение на диск.
2. Durable — будет восстановлена после перезапуска сервера.
А обычные очереди, просто кидают сообщения в буфер для записи на диск.
Чтобы проверить как это работает, поставьте ребит на виртуалку с очень маленьким объёмом памяти и пишите много всего в non-durable очередь. Ничего не выпадет, всё будет хорошо работать и ребит скорее всего будет использовать совсем немного памяти, просто отправка будет не такой быстрой.
1. Durable — не отпускает вас, пока не запишет сообщение на диск.
2. Durable — будет восстановлена после перезапуска сервера.
А обычные очереди, просто кидают сообщения в буфер для записи на диск.
Чтобы проверить как это работает, поставьте ребит на виртуалку с очень маленьким объёмом памяти и пишите много всего в non-durable очередь. Ничего не выпадет, всё будет хорошо работать и ребит скорее всего будет использовать совсем немного памяти, просто отправка будет не такой быстрой.
Софт на java.
Тут согласен — стоило всё же включить его в тесты.
Использовал. Только с durable очередями возможно организовать репликацию active-active в рэбите.
Сперва про пакетную обработку — если вы про префетчинг в Rabbit MQ, то его как правило все используют и не гоняют по одному сообщению.
Тут согласен — стоило всё же включить его в тесты.
Ещё из статьи не понял использовали вы durable очереди RabbitMQ
Использовал. Только с durable очередями возможно организовать репликацию active-active в рэбите.
Насчет того, что в HTTP большую часть времени занимает установка соединения — категорически рекомендую использовать HTTP клиент с поддержкой keep-alive.
А можно тут подробнее?
Я не знаю поддерживает ли SQS HTTP/1.1 Keep-alive, но суть в том, что клиент и сервер не закрывают TCP соединение после запроса-ответа, а держат его открытым некоторое время.
Без keep-alive клиент:
1. Oткрыл TCP подключение
2. Отправил запрос
3. Cчитал ответ (заголовки + Content-Size байт body)
4. Закрыл TCP подключение
Если нужно выполнить несколько запросов подряд — эта последовательность повторяется целиком для каждого запроса
С keep-alive клиент:
1. Открыл TCP подключение
2. Отправил запрос
3. Cчитал ответ (заголовки + Content-Size байт body)
4. Положил открытый сокет в пул не закрывая.
Если нужно выполнить несколько запросов подряд — сперва заглядываем в пул — нет ли уже открытого соединения. Если есть, выполняем шаги 2-4, если нет — то 1-4.
Сокет закрывается по таймауту.
А есть ещё HTTP пайплайнинг — это когда в сокет отправляется сразу 5-10 запросов подряд, а потом в том же порядке считываются сразу все ответы (Nginx поддерживает, браузеры кто как).
По моим бенчмаркам, при работе с keep-alive и без с Nginx количество запросов в секунду отличается на порядок.
Без keep-alive клиент:
1. Oткрыл TCP подключение
2. Отправил запрос
3. Cчитал ответ (заголовки + Content-Size байт body)
4. Закрыл TCP подключение
Если нужно выполнить несколько запросов подряд — эта последовательность повторяется целиком для каждого запроса
С keep-alive клиент:
1. Открыл TCP подключение
2. Отправил запрос
3. Cчитал ответ (заголовки + Content-Size байт body)
4. Положил открытый сокет в пул не закрывая.
Если нужно выполнить несколько запросов подряд — сперва заглядываем в пул — нет ли уже открытого соединения. Если есть, выполняем шаги 2-4, если нет — то 1-4.
Сокет закрывается по таймауту.
А есть ещё HTTP пайплайнинг — это когда в сокет отправляется сразу 5-10 запросов подряд, а потом в том же порядке считываются сразу все ответы (Nginx поддерживает, браузеры кто как).
По моим бенчмаркам, при работе с keep-alive и без с Nginx количество запросов в секунду отличается на порядок.
Sign up to leave a comment.
Amazon SQS vs RabbitMQ