sunman Jun 27 2018 at 15:03

Львы в пустыне и интроспекция

6 min

7.3K

Laravel*PHP*

+10

Comments 17

Zagrebelion Jun 27 2018 at 15:15

(недоумевающий взгляд из лагеря питона)
А что, пхп в 2018 году не умеет при смерти показывать стэктрейс?

sunman Jun 27 2018 at 15:43

PHP интерпретатор, в том случае, когда падает PHP-программа — так и делает.
Только в данном случае падал сам интерпретатор, и на консоль при этом выводил только краткое "Segmentation fault (core dumped)".

m0rtis Jun 27 2018 at 15:47

Вы меня опередили:)) Как раз и хотел сказать, что если бы интерпретатор был бы жив, он бы вывел стэктрейс. А тут он умирал, ничего не успев оставить потомкам.
Сомневаюсь, что какой-либо интерпретируемый язык может как-то иначе.

sunman Jun 27 2018 at 15:52

Ну потомкам он оставляет этот самый core dump, который надо брать и разбираться, отчего упал интерпретатор. Могла бы быть еще отладочная информация в консоли, если бы интерпретатор PHP (а он написан на C) был скомпилирован с соответствующими настройками.

andreymal Jun 28 2018 at 00:35

php-fpm — это не модуль, а очень даже сервер (хотя в документации напрямую об этом почему-то не сказано), работающий абсолютно независимо от nginx, который в вашем случае слушает юникс-сокет /var/run/php/php7.1-fpm.sock (хотя при желании можно перенастроить и на прослушку обычного TCP-порта), и nginx очень даже проксирует запросы в этот сокет, так что ошибка 502 абсолютно нормальная

VolCh Jun 28 2018 at 08:45

Людей часто вводит в заблуждение о природе отношений веб-сервера и php-fpm незнание о существовании клиент-серверного протокола FastCGI.

VolCh Jun 28 2018 at 08:56

Статический анализатор для PHP-кода исключил бы возможность воспроизвести баг для C-кода :)

Если кто не в курсе, то core dump практически однозначное свидетельство наличия бага в коде того процесса, который собственно сдампился. Если крашится процесс php значит ошибка в самом C коде php или используемых им библиотек, пускай даже добраться до неё получается только при наличии ошибки в PHP коде приложения или каких-то битых данных, поданных на вход PHP

lleo_aha Jun 28 2018 at 09:46

Какая страшная статья вышла.
На старте «но у меня же нет upstream server» хотя он есть
Внутри — использование reflection для продакшен функционала
По факту — выбрасывание эксепшена в эксепшен хендлере

greabock Jun 28 2018 at 12:08

использование reflection для продакшен функционала

Эм… ну как бы это норма. Любой нормальный DI-контейнер работает на рефлексии (Хоть sf, хоть laravel, хоть php-di. А как иначе-то?). Аннотации (doctrine/annotations) работают на рефлексии. Никто их из продакшена не попёр за это. Да кучу всего интересного можно сделать на рефлексиях. У меня в приложении гидратор самописный тоже этой наркотой балуется.

sunman Jun 28 2018 at 12:19

Ну мне уже коллега в устном разговоре попенял за использование рефлексии в коде сервиса, сказав, что она — сильно медленная штука. И как пример ее уместного использования упомянул как раз про doctrine, где, с использованием аннотаций и рефлексии, генерится PHP-код работы с сущностями. Далее результат кодогенерации кешируется, и после этого рефлексия больше не применяется — до следующего изменения аннотаций. Думаю переделать свой вывод констант с backend в JS по этой же схеме.

SerafimArts Jun 28 2018 at 14:02

Рефлексия очень медленная в Java, а в PHP скорость такая же, как и у других классов или функций. По крайней мере явного проседания нет.

Предлагаю самостоятельно проверить скорость работы пары вызовов оной.

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

Fesor Jun 29 2018 at 11:34

> кодогенерация — это ещё большее зло

вот часто это слышу но как-то никогда нет аргументов. Обычно просто пересказ того что говорят другие. при этом другие обычно говорят о том виде кодогенерации, которая не воспроизводима. То есть ты сгенерил код и не можешь его «обновить» перегенерив.

А если у тебя есть DSL по которому генерится код — в чем проблема? это намного лучше чем интерпритация в рантайме банально потому что дебажить такое проще.

SerafimArts Jun 29 2018 at 13:37

вот часто это слышу но как-то никогда нет аргументов. Обычно просто пересказ того что говорят другие. при этом другие обычно говорят о том виде кодогенерации, которая не воспроизводима. То есть ты сгенерил код и не можешь его «обновить» перегенерив.

Я про практику в этом случае. php-deal просто не будет работать с доктриной, как и другие подобные штуки.

А если у тебя есть DSL по которому генерится код — в чем проблема? это намного лучше чем интерпритация в рантайме банально потому что дебажить такое проще.

А DSL уже не код, там АОП не применишь, так что пофигу)

VolCh Jun 29 2018 at 11:53

В целом есть заметное проседание между вариантами (в порядке уменьшения скорости):
— прямое присваивание значения «статическому» свойству
— прямое присваивание значения динамическому свойству
— присваивание через сеттер
— присваивание через __set
— присваивание через \Closure
— присваивание через рефлексию

Кодогенерация нормальный подход. по сути это лишь компиляция какого-то DSL в исполняемый код.

Fesor Jun 29 2018 at 11:33

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

VolCh Jun 29 2018 at 12:09

Нормальный DI-контейнер работает на штатной рефлексии (или, как вариант, на построении пользовательского AST непосредственно по коду) в продакшен-режиме максимум один раз на конкретной кодовой базе, в идеале до собственно первого продакшен-запроса к ней.

zim32 Jun 28 2018 at 13:24

История одной отладки? О чем статья?