Comments 25
del
А может кто-нибудь поделиться своим мнением по поводу целесообразности использования Swoole/RoadRunner? Про принципы работы я почитал, некую картину себе обрисовал, но хотелось бы реального фидбека от людей, которые перешли на них с php-fpm.
В каких случаях игра реально стоит свеч? Какие реальные основные преимущества вы для себя подметили?
Строже код, меньше костылей чтобы работало быстро. Но у нас свой тулкит.
Примерно полтора года назад я с коллегой нагрузил яндекс танком road runner и была ситуация, что мне в ответ прилетели куки коллеги, а ему — мои. Это происходило редко и только при нагрузке. После этого я больше не смотрел в сторону road runner. Возможно, это была проблема в коде, но это был примитивный код, и с куками никакой работы в коде не было. Ни в коем случае не хочу сказать «нельзя использовать», но протестировать и нагрузить стоит.
К слову, подобная ситуация была недавно на гитхабе, но конечно по другим причинам
Это была проблема в коде, скорее всего у вас был стейтфул кук коллектор
Это был lumen с практически пустым контроллером. Но все может быть
Просто в РР нет стейтфул кода, утечка стейта может быть только из PHP. Зная особенности дизайна Laravel можно предположить что это именно проблема Lumen.
В ларе особый идиотизм с хранением реквеста в di-контейнере.
Копнул — да, все фасады работают как синглтоны github.com/laravel/framework/blob/8.x/src/Illuminate/Support/Facades/Facade.php
Т.е. при работе через фасад какой-то реквест будет закэширован в синглтоне
В симфоне тоже реквест стек лежит в контейнере. Это кажется нормальным.
Это перестанет казаться нормальным сразу как только вы захотите обработать два последовательных реквеста без реинициализации всего приложения с контейнером
С этим нет никакой проблемы. В контейнере, если прочитать внимательно, лежит не реквест, а реквест стек (реквестов на самом деле уже сейчас в симфоне может быть несколько одновременно, т.к. есть т.н. subrequests для рендера фрагментов, внутренних форвардов и пр.)
В этот самый стек реквест пушится на старте его обработки ядром https://github.com/symfony/http-kernel/blob/5.x/HttpKernel.php#L129
И попается оттуда при завершении его обработки
https://github.com/symfony/http-kernel/blob/5.x/HttpKernel.php#L207
Времена, когда в контейнере хранился именно реквест закончились с приходои симфони 3, а это было несколько лет назад. С тех пор все хорошо и кажется нормальным :)
Это все хорошо. Но исходная моя реплика была следующей
В ларе особый идиотизм с хранением реквеста в di-контейнере
И именно на неё вы ответили — это кажется нормальным.
Резюме.
Хранить в контейнере обработчики — это ок.
Хранение состояния приложения в di-контейнере это, мягко выражаясь, грустно.
Из минусов:
- Переезд на PSR-7 для legacy проектов. В 85% случаев не было проблем, некоторые же части надо было перепиливать
- Постоянные коннекты к базе/redis/etc. В случае 1 проекта можно легко рассчитать нужное кол-во открытых соединений, но когда у тебя 3-4 RoadRunner'а и несколько php-fpm можно внезапно упереться в лимит
- RoadRunner не всегда перезапускает умершие воркеры. Использую еще пока 1 версию, не 2. Лечится опрашиванием по крону 2114 порта (Healthcheck) и перезапуском. Возможно, косяк во мне
- Чуть сложнее дебаг
- Прослойка в лице nginx остается в случае отдачи контента пользователю, но в случае каково-то api он не нужен
- Нужно смотреть за памятью. Сейчас у нас docker-контейнер с 50 воркерами потребляет 7.5 гб памяти, но я некоторые вещи кеширую прямо в PHP массиве ради быстродействия. maxMemory у воркеров стоит в 250 мб и отключен gc. У другого контейнера с 300 воркерами потребление в 2.2 гб
Спасибо!
Блин, запилил велосипед для mysqli, не прошло и 10 лет, они нормально бинды сделали
тулза spatie/period очень пригодится, самому сложно отслеживать «а что вообще есть».
PHP Дайджест № 201 (15 – 29 марта 2021)