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

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

В каком-то смысле это даже сыграло в плюс, потому что теперь для кода будет полноценно использоваться GitHub и это удобнее.

Но Расмус и Никита сильно напряглись, когда узнали о тех коммитах :)

А может кто-нибудь поделиться своим мнением по поводу целесообразности использования Swoole/RoadRunner? Про принципы работы я почитал, некую картину себе обрисовал, но хотелось бы реального фидбека от людей, которые перешли на них с php-fpm.
В каких случаях игра реально стоит свеч? Какие реальные основные преимущества вы для себя подметили?

Когда нужна высокая производительность и другими средствами уже не получается получить больше.

Строже код, меньше костылей чтобы работало быстро. Но у нас свой тулкит.

Примерно полтора года назад я с коллегой нагрузил яндекс танком road runner и была ситуация, что мне в ответ прилетели куки коллеги, а ему — мои. Это происходило редко и только при нагрузке. После этого я больше не смотрел в сторону road runner. Возможно, это была проблема в коде, но это был примитивный код, и с куками никакой работы в коде не было. Ни в коем случае не хочу сказать «нельзя использовать», но протестировать и нагрузить стоит.
К слову, подобная ситуация была недавно на гитхабе, но конечно по другим причинам

Это была проблема в коде, скорее всего у вас был стейтфул кук коллектор

Это был lumen с практически пустым контроллером. Но все может быть

Просто в РР нет стейтфул кода, утечка стейта может быть только из PHP. Зная особенности дизайна Laravel можно предположить что это именно проблема Lumen.

Я бы сказал, что это в принципе проблема смены парадигмы, стейт больше не умирает при завершении запроса и много кода может быть банально не готовым к такому повороту вещей. Надо задумываться о куче вещей сразу, чистить идентити мапы доктрины, всякие временные кэши. Весь код, который работает на статиках или глобалах здесь сразу подвержен уязвимостям, потому что в целом простым решением было бы переинициализировать контейнер (его содержимое), чтобы весь сервисный стек был создан заново. Но со всякими синглтонами такое не проканает. Зная любовь лары к статик колам, не удивлюсь, что проблема, действительно, именно там

В ларе особый идиотизм с хранением реквеста в di-контейнере.

В симфоне тоже реквест стек лежит в контейнере. Это кажется нормальным. Вопрос не в том, в 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-контейнере это, мягко выражаясь, грустно.

Не так понял вашу мысль, да, подумал что вы сетуете на хранение реквеста в DI в любом виде. Еще же есть вариант писать стейтлесс приложения, чтобы вся логика получала реквест через аргументы вызова, например (примерно как всяческие middleware), подумал что вы об этом

Мы используем RoadRunner и мне он больше понравился чем не понравился.
Из минусов:
  • Переезд на 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 лет, они нормально бинды сделали

Я уже несколько лет смотрю на жёлтого PHP слоника и… Где его взять?!
Там даже лучше, в наличии минус 12 слонов.
спасибо за обзор,
тулза spatie/period очень пригодится, самому сложно отслеживать «а что вообще есть».
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.