Как стать автором
Обновить

Комментарии 22

Связка php+librabbitmq выдавала нам 300-600 rps, но тут дело, в основном, в конечном числе воркеров php.

Как то сильно мало ресурсов наверно, у меня на обычном i7 выдавало на одном воркере 1500-2000 (судя по показаниям самого кролика).

И еще момент, не смотрели на плагин:
rabbitmq_jsonrpc_channel
An AMQP-over-HTTP protocol binding for RabbitMQ and some Javascript libraries for interacting with RabbitMQ over HTTP.
Есть в списке на сайте: www.rabbitmq.com/plugins.html
Там много времени постоянно тратится на connect. А librabbitmq-0.0.1 не умеет keepalive. Следующие версии вроде умеют уже, но надо рефакторить код, изменился интерфейс.
В случае с rabbitmq_jsonrpc_channel там проблемы, если сеть нестабильна. Состояние channel не меняется, в случае разрывов сети имеем ошибку и прекращение операций. Надо дописывать как-то прибитие канала. Есть какие-то таймауты, но под нагрузкой в общем все печально выглядит ))
Сейчас найти не могу сходу, но я где-то читал, что такая штука не для production, больше для девелоперских нужд.
Наш Yii фреймворк использует этот метод, как резервный, когда все остальное не сработало.
А использовать связку с node вместо php пробовали?
node.js пока в планах. Хочется не все сразу сломать и заново написать, а потихоньку начать с совсем проблемных мест ))
Как вы собираете amqp пакет на фронтенде? Возможно создание amqp пакета следует перенести на серверную часть. Тогда вам подойдет любой легкий web сервер, который обработает ajax запрос от клиента и отдаст результат в rabbit.
Где много php схема такая
Запрос — Nginx — php(парсим, считаем, формируем пакет) — отсылаем с помощью php.
Логики внутри много, считать много, есть контент, который надо потом еще и отдавать — выглядит и работает не очень быстро, надо исправлять. Поэтому думаем над тем, чтобы часть логики перенести на сервер в Nginx as web-application.
Можно разумно поспорить, что фронтенд должен быть легковесным, не перегруженным, что лишние модули — это оверхед, что логика — это не задача фронтенда, что программировать на Nginx — неправильно. Но я вот лично вижу, что такой подход получается все же быстрее, чем традиционный. Главное без фанатизма и не переборщить.

Где контента нет и можно вообще в принципе php убрать, так и получается, как в статье и как в вашем комментарии. Проблема была как раз в том, чтобы научить сервер, в данном случае фронтенд Nginx — говорить с кроликом напрямую, без всяких прослоек и комбайнов, которые надо инициализировать, дозировать воркеры, выделять память.
Резонно заметить, что мы убрали php, но взяли вдруг вместо него perl, но тут уровень и слой абстракции все же пониже, поэтому быстрее в 10 и более раз. Это все если переписать еще дальше и проще, будет наверняка еще быстрее, но не хватает скилла к сожалению )))
Да, еще такой важный момент. Мы проповедуем DevOps, но тут получается такая интересная штука. По крайней мере у нас, где много продуктов и людей.
Если часть логики работы приложения скриптовать и переносить на фронтенды, то встает еще вопрос, чья область ответственности эти скрипты. Программистов или системных администраторов?) Кто их будет писать, тестить и деплоить. Кто будет обеспечивать интеграцию? У программиста есть фреймворк, классы, методы, интерфейсы. У системного администратора есть nginx.conf. До какого момента кого куда можно пускать: программиста на сервер, а админа в код?)
Именно об этом же я написал в своем каменте ниже. Пока писал свой камент ты меня опередил :)
У вас хорошая оптимизация получилась, всё правильно. )
Альтернативный вариант — написать плагин к rabbitmq, там уже есть wrapper-ы для двух встраиваемых http серверов. Это избавит от посредников.
На самом деле подход очень интересный и его стоит посмотреть с разных сторон.

Что касается проблем: первое что уже видится сейчас это перенос логики в другую «подсистему». Получается так что у нас есть php-программист который может сделать реализацию на php. Но мы уже начинаем писать a) на perl б) на стороне nginx. Ладно, пусть язык программирования не важен, но вот вроде за nginx отвечает системный администратор. Вопрос — кто должен отвечать за код на стороне nginx?
С одной стороны программист — ему же нужно напистаь код, выполняющий задачу. С другой — админ, ведь это же его часть и он за неё отвечает. А что если нужно будет менять реализацию, править там что-то?
Правит программист — админ не в курсе правок. Правит админ — программист не в курсе. Симбиоз? Совместно?
Вот тут пока не понятно как быть. Давайте порассуждаем?
Это вот как раз, вроде, не проблема.

Конфиги не надо рулить руками, надо рулить конфигами через puppet, например. Манифесты лежат в git — все правки всем видны.
Ну т.е. всётаки программист пишет перловый скрипт и какую-то часть конфига nginx. Админ потом это всё раскладывает с очередным релизом, при необходимости люди коммуницируют делают что-то совместно, либо кто-то кому-то ставит задачу что нужно что-то сделать.
Я не вижу зачем нужен админ для конфига nginx-a, ну только если рассказать программистам как его готовить. Сети, железо, сеть, мониторинг, файрволы — это явно задачи админов. Конфиг же nginx-a сильно повязан с приложением, если мы чуть более сложные задачи рассматриваем, и тут стоит поставлять решение для развертывания комплексно — манифестом с пакетами и конфигами. Ну это конечно зависит от проекта. С другой стороны на маленьком проекте надобность в админе сомнительна.
за это время (2 года) — много воды утекло, librabbitmq перестала поддерживаться официально и переехала на гитхаб, вышел второй раббит, перешли на более высокую версию AMQP
>Он прожует хоть сто тысяч рпс, но вот бекенд уже нет.
ну тут Борис, ты не прав… учи Си и у тебя не будет проблем с производительностью.
nginx — не такой быстрый, как ты считаешь. Написать аналог AMQP-rest — это не более недели. Запускается за nginx — исключительно потому-чтобы лишний раз не утежелять nginx, который тяжелеет и тяжелеет от версии к версии.
вроде как с кроликом не совместим?
хотя 0mq достойная замена кролю, если не нужен кластер.
Ну вот они писали про плагин для кролика, который открывает 0MQ сокет, но он не работает сейчас. Собирается и не работает.

RabbitMQ — это брокер из коробки. Есть центральная нода с кучей логики, она обрабатывает все сообщения прежде чем отправить клиентам.

ZeroMQ — это фреймворк, позволяющий написать свою систему. Надо будет самому придумывать, реализовывать логику и наполнять нодами.

Второе, несомненно, быстрее работает. Но также более трудоемко в реализации.

Вообще хочется уже гибридную среду, где есть и то, и то.

zmq может все, что делает кролик и больше
я использовал github.com/akalend/amqp-rest который стоял за nginx
может кому пригодится

Производительность на тестовом двухядерном старом сервере
PERFORMANCE

ab -c 50 -n 1000 10.0.0.1:8080/xxx/q2

concurrency Level: 50
Time taken for tests: 0.745 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 84000 bytes
HTML transferred: 21000 bytes
Requests per second: 1342.95 [#/sec] (mean)
Time per request: 3.723 [ms] (mean)
Time per request: 0.745 [ms] (mean, across all concurrent requests)
Transfer rate: 110.16 [Kbytes/sec] received
Интересно как это работает спустя 3 года,
хочу разочаровать автора… так как, когра её читал ранее, то знал об асинхронности на много меньше :)
так как предлагает делать автор —

Был найден wrapper для librabbitmq на perl. К счастью, nginx умеет embedded perl.

ТАК ДЕЛАТЬ НЕЛЬЗЯ!!!

librabbitmq — это блокируемая библиотека, её НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ КАК МОДУЛЬ NGINX,
как вариант, возможно только через upstreem с подзапросами.

Я тоже, лет 5-7 назад страдал написанием модулей под nginx с блокирующими сокетами. Со временем понял ашыпки…

Сейчас, единственное решение — это использование модуля OpenResty Stomp https://github.com/wingify/lua-resty-rabbitmqstomp с установкой STOMP плагина в RabbitMQ.

Модуль https://github.com/AlanWangWP/nginx-rabbitmq тоже использовать нельзя, так как использует librabbitmq-c.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории