Roadrunner у нас в качестве эксперимента, в 1 системе на фреймворке Slim. По характеру, приложение — это большое количество довольно простых API, работающих с базой.
Самый главный вопрос, конечно, есть ли увеличение производительности. Достовернее всего было бы сравнить одно и то же приложение на roadrunner и php-fpm, но нам это пока только предстоит. Если грубо и быстро сравнить время ответа этого с сервиса с похожим приложением на php-fpm, то у rr 95-ая персентиль довольно ровно лежит в районе 0.090s, когда как у php-fpm приложения, колеблется в около 0.230s с скачками вверх. Звучит хорошо, но лучше, конечно, сравнивать сравнимое, мало ли почему так.
Из плюсов использования, например, из коробки prometheus-endpoint есть с пачкой метрик о прожорливости и вообще жизнедеятельности сервиса roadrunner.dev/docs/beep-beep-metrics
Из минусов, нельзя использовать stdout для логов, он нужен самому roadrunner для сборки response, приходится изворачиваться github.com/spiral/roadrunner/issues/208, ещё и внутренний механизм логирования не очень-то конфигурируется. Обещают в 2.0 переделать. Приходится дополнительно настраивать dev-режим, он отличается от привычного php-разработчику и поэтому не всем нравится. Ещё на этапе стабилизации смутно помню были какие-то нюансы с передачей правильных header'ов для json.
В общем, технология экзотичная, с нюансами. Справиться с ними можно, но хорошо бы понимать ради чего. Даст ли он для вашего приложения ощутимую производительность и действительно ли она вам нужна.
https://www.vedomosti.ru/economics/articles/2018/10/17/783943-dolyu вот была публикация, 3 трлн это оценка. Про сами статьи вот http://www.consultant.ru/document/cons_doc_LAW_19702/3c4b8d1ce0bfd52b1c632bb8812514eb194cea19/
Самый главный вопрос, конечно, есть ли увеличение производительности. Достовернее всего было бы сравнить одно и то же приложение на roadrunner и php-fpm, но нам это пока только предстоит. Если грубо и быстро сравнить время ответа этого с сервиса с похожим приложением на php-fpm, то у rr 95-ая персентиль довольно ровно лежит в районе 0.090s, когда как у php-fpm приложения, колеблется в около 0.230s с скачками вверх. Звучит хорошо, но лучше, конечно, сравнивать сравнимое, мало ли почему так.
Из плюсов использования, например, из коробки prometheus-endpoint есть с пачкой метрик о прожорливости и вообще жизнедеятельности сервиса roadrunner.dev/docs/beep-beep-metrics
Из минусов, нельзя использовать stdout для логов, он нужен самому roadrunner для сборки response, приходится изворачиваться github.com/spiral/roadrunner/issues/208, ещё и внутренний механизм логирования не очень-то конфигурируется. Обещают в 2.0 переделать. Приходится дополнительно настраивать dev-режим, он отличается от привычного php-разработчику и поэтому не всем нравится. Ещё на этапе стабилизации смутно помню были какие-то нюансы с передачей правильных header'ов для json.
В общем, технология экзотичная, с нюансами. Справиться с ними можно, но хорошо бы понимать ради чего. Даст ли он для вашего приложения ощутимую производительность и действительно ли она вам нужна.