Comments 16
хорошая статья, спасибо за информацию
я не использовал prefetchcount (кажется в первой версии его нет)
сообщения брал асинхронно по GET
в этом случае сообщения раздаются равнмерно всем воркерам
я не использовал prefetchcount (кажется в первой версии его нет)
сообщения брал асинхронно по GET
в этом случае сообщения раздаются равнмерно всем воркерам
Вообще-то для организации одной очереди я бы использовал ZMQ, Redis, MemcechedQ или Gaerman
это будет более производительней
Раббит — он подходит больше для очередей с логикой.
это будет более производительней
Раббит — он подходит больше для очередей с логикой.
На проекте, разумеется, куда более сложная организация очередей и консумеров, просто сравнительные тесты производились на примере одной конкретной очереди.
Вот, как всегда, про самое интересное замолчали…
Какие типы очередей используются? Какой роутинг ключей?
спектр задач?
Какие типы очередей используются? Какой роутинг ключей?
спектр задач?
Интересующимуся Хабросообществу прежде всего любопытна область применения данной технологии,
причины выбора именно этой технологии ( причина: модно не приветствуется, но подразумевается по умолчанию, если иное не указано) и ее отличительные черты от смежных технологий, а потом уже конкретные детали и исследования.
так на будущее, замечание к последующим статьям
причины выбора именно этой технологии ( причина: модно не приветствуется, но подразумевается по умолчанию, если иное не указано) и ее отличительные черты от смежных технологий, а потом уже конкретные детали и исследования.
так на будущее, замечание к последующим статьям
Целью этой статьи было описать особенности работы с prefetchCount, как подойти к выбору его значения.
А описание, почему и как используется RabbitMQ на нашем проекте, далеко выходит за эти рамки. Возможно, оно будет позже.
А описание, почему и как используется RabbitMQ на нашем проекте, далеко выходит за эти рамки. Возможно, оно будет позже.
Вы верно подметили выше, очереди с логикой. Конкретно наш выбор RabbitMQ был основан на том, что очередь была уже нужна, но что-то отдельно писать и выдумывать было особо некогда. У нас несколько проектов-сателлитов вокруг одного большого. И очереди служат для обмена разной информацией. Как служебной — статистика, которая может быть локальной, а может отсылаться во внешние сервисы аналитики. Так и проектной — например, различные рекламные рейты, которые пересчитываются где-то, но от них зависит, что в итоге покажут пользователю.
Из коробки ставим RabbitMQ и почти все работает:
— производительность
— отказоустойчивость
— персистентность
— подтверждение доставки и прочтения
— высокая доступность
— гибкий роутинг
— плагины
На самом деле есть и минусы у данного решения. Оно медленнее, чем все остальное, часто непонятно что там сломалось и когда, и почему. Часто заявленные фичи — не совсем то, что ожидаешь. Например, кластеринг не очень.
Но все это развивается и пилится, каждый релиз добавляет функционал.
В случае rabbitMQ можно с помощью плагинов, например, открыть (не полностью функциональный) zMQ сокет, позволяя комбинировать разные типы транспорта.
У нас есть все типы очередей и ексчейнджей, также мы используем шоувелы для обмена информацией между большими кроликами.
Из коробки ставим RabbitMQ и почти все работает:
— производительность
— отказоустойчивость
— персистентность
— подтверждение доставки и прочтения
— высокая доступность
— гибкий роутинг
— плагины
На самом деле есть и минусы у данного решения. Оно медленнее, чем все остальное, часто непонятно что там сломалось и когда, и почему. Часто заявленные фичи — не совсем то, что ожидаешь. Например, кластеринг не очень.
Но все это развивается и пилится, каждый релиз добавляет функционал.
В случае rabbitMQ можно с помощью плагинов, например, открыть (не полностью функциональный) zMQ сокет, позволяя комбинировать разные типы транспорта.
У нас есть все типы очередей и ексчейнджей, также мы используем шоувелы для обмена информацией между большими кроликами.
К вышесказанному я бы добавил, что мы проводили внутренний сравнительный анализ множества мессенджеров или близких к ним технологий — Joram MQ, HornetQ (JBoss), ActiveMQ (Apollo, JMS), Qpid, Kestrell, ZeroMQ и прочих.
И в результате всё-равно выбрали именно Rabbit. Причин тому несколько, но среди ключевых — уникальная модель управления очередями. Консьюмер сам может указать серверу очереди и типы сообщений, которые ему нужны. Это на практике — очень эффективный инструмент. Выкладывать детальное сравнение нет возможности — оно не доведено до качества хорошей статьи, но в целом, сочетание скорости, удобства, стабильности (миллионы сообщений держит), настраивоемости, визуального управления и очень удобной модели работы с очередями — даёт много очков именно этому решению.
Но если стоите перед выбором — посмотрите HornetMQ. По тестам скорости, например, он давал лучшие результаты.
И в результате всё-равно выбрали именно Rabbit. Причин тому несколько, но среди ключевых — уникальная модель управления очередями. Консьюмер сам может указать серверу очереди и типы сообщений, которые ему нужны. Это на практике — очень эффективный инструмент. Выкладывать детальное сравнение нет возможности — оно не доведено до качества хорошей статьи, но в целом, сочетание скорости, удобства, стабильности (миллионы сообщений держит), настраивоемости, визуального управления и очень удобной модели работы с очередями — даёт много очков именно этому решению.
Но если стоите перед выбором — посмотрите HornetMQ. По тестам скорости, например, он давал лучшие результаты.
Вообще в оффициальном гайде пробоема неодновременного старта консумера тоже описана — и более того там придется писать свой велосипед по ее решению — например не начинать диспечеризацию пока определеная процент системы не сообщит о готовности приниамать сообщения.
ИМХО, все конечно зависит от проекта
Зная характер задачи, мы можем оценить время ее исполнения или оценить загруженность воркера.
Соответственно, для более тяжелых воркеров я бы организовал свою отдельную очередь.
Зная характер задачи, мы можем оценить время ее исполнения или оценить загруженность воркера.
Соответственно, для более тяжелых воркеров я бы организовал свою отдельную очередь.
В наших тестах получалась следующая картина:
— совсем маленькие значения PrefetchCount заметно влияют на производительность. Причем, prefetch=1 и prefetch=2 довольно сильно отличаются. При 10 консьюмерах получалось 10000/15000 сообщений в секунду.
— prefetch=20, prefetch=50, prefetch=10000 — разница незначительна, порядка 35000 в секунду.
— чем больше latency у сети, тем больше выигрыш от более высоких значений prefetch, но при достижении некоторых лимитов — выигрыш незаметен практически.
— совсем маленькие значения PrefetchCount заметно влияют на производительность. Причем, prefetch=1 и prefetch=2 довольно сильно отличаются. При 10 консьюмерах получалось 10000/15000 сообщений в секунду.
— prefetch=20, prefetch=50, prefetch=10000 — разница незначительна, порядка 35000 в секунду.
— чем больше latency у сети, тем больше выигрыш от более высоких значений prefetch, но при достижении некоторых лимитов — выигрыш незаметен практически.
Sign up to leave a comment.
Оптимизация обработки сообщений RabbitMQ