pronskiy Mar 29 2021 at 11:55

PHP Дайджест № 201 (15 – 29 марта 2021)

6 min

12K

Website development*PHP*Symfony*Yii*Laravel*

+37

Comments 25

StudioMaX Mar 29 2021 at 12:14

Также вчера в официальном репозитории git.php.net появилось два бэкдора, которые позже поревертили. Информация из рассылки.

pronskiy Mar 29 2021 at 12:15

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

slaFFik Mar 29 2021 at 20:33

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

Gemorroj Mar 29 2021 at 12:28

del

Jokerzp Mar 29 2021 at 15:35

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

pronskiy Mar 29 2021 at 17:00

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

Lachezis Mar 29 2021 at 21:39

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

xxxcoltxxx Mar 29 2021 at 23:47

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

Lachezis Mar 30 2021 at 11:06

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

xxxcoltxxx Mar 30 2021 at 11:08

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

Lachezis Mar 30 2021 at 11:11

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

pbatanov Apr 1 2021 at 12:31

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

Fortop Apr 1 2021 at 18:31

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

pbatanov Apr 1 2021 at 19:02

В симфоне тоже реквест стек лежит в контейнере. Это кажется нормальным. Вопрос не в том, в di или нет, а в том, каким образом оно инициализиуется.
Копнул — да, все фасады работают как синглтоны github.com/laravel/framework/blob/8.x/src/Illuminate/Support/Facades/Facade.php
Т.е. при работе через фасад какой-то реквест будет закэширован в синглтоне

Fortop May 1 2021 at 11:10

В симфоне тоже реквест стек лежит в контейнере. Это кажется нормальным.

Это перестанет казаться нормальным сразу как только вы захотите обработать два последовательных реквеста без реинициализации всего приложения с контейнером

pbatanov May 1 2021 at 12:15

С этим нет никакой проблемы. В контейнере, если прочитать внимательно, лежит не реквест, а реквест стек (реквестов на самом деле уже сейчас в симфоне может быть несколько одновременно, т.к. есть т.н. 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, а это было несколько лет назад. С тех пор все хорошо и кажется нормальным :)

Fortop May 2 2021 at 10:19

Это все хорошо. Но исходная моя реплика была следующей

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

И именно на неё вы ответили — это кажется нормальным.

Резюме.
Хранить в контейнере обработчики — это ок.
Хранение состояния приложения в di-контейнере это, мягко выражаясь, грустно.

pbatanov May 2 2021 at 12:04

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

WiFi_3 Mar 30 2021 at 13:52

Мы используем 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 гб