Тоже давно следил за аналитикой у Подоляки, но стало видно как его субъективность преобладала над объективностью пару недель назад. Особенно заметно на последнем видео (уже кстати на рутубе) про Краматорск, когда он на основании всего лишь одного довода сделал однозначный вывод. А если посмотреть интерпретацию про те же события от Каца, там высказано несколько доводов (в противоположном направлении) и только тогда сделан вывод. Подоляка сознательно или нет (думаю все же не специально, а как защитный психологический механизм, став заинтересованной стороной своих обзоров), но перестал упускать/пропускать объективные факты.
openswoole по ощущениям (после отпочкования) начал быстрее развиваться и в более правильную сторону. Перешли на него. Но не факт что выбор правильный.) В целом разницы сейчас особо нет, пока они взаимозаменяемые плюс-минус (другой докер имидж сбилдил и готово), если не считать последних фич...
Так а что вы пытались мерять с помощью newrelic? TTFB (время ответа бекенда)? Так это как из пушки по воробьям. Это надо делать другими инструментами (мы на текущий момент забираем эту статистику из nginx ingress который балансировщиком стоит на фронте и логирует upstream response time).
После того как все устаканилось, есть планы протестировать и буст от JIT, и вопрос мультиплексирования vs многопоточности. Благо это не сложно - отключить корутины и поднять очень много воркеров, это 2 параметра по сути.
Ещё скоро перейдем на 8.1, тоже потестим.
Насчёт роадранера или оптимизаций для fpm я поясню, решение про переход на swoole принималось в дополнение к другим факторам: на тот момент проекту исполнилось 5 лет (и я напомню что это самопис): за это время там накопилось очень много легаси (причем речь не про бизнес код, а про сторонние пакеты), все это мешало апгрейдам (на тот же 8.0), мешало применять бест практис.
То есть кроме Swoole, мы перешли на 8.0, убрали все легаси пакеты (доктрины, симфони, убрали старые zend framework пакеты), переделали структуру проекта по DDD канонам и перешли на мидлвари и хттп хендлеры (PSR стандарты).
Поэтому решение использовать Swoole вместо Roadrunner (на тот момент эта была ещё первая версия) была принята осознано для того чтобы из коробки получить асинхронное IO.
В планах в дополнение к JSON API попробовать gRPC и общение клиентов по Websocket'ам. И текущая архитектура к этому уже готова (то есть Swoole это даст из коробки).
Newrelic показывал что процессорное время тратилось на такие банальные вещи как композеровский автолоадинг (было около 400 пакетов), на доктриновскую гидрацию (из всего времени php эти 2 вещи 60% времени занимали) и только потом вся бизнес логика и сверху ещё IO (который при бустрапинге тоже был - например чтение файлов кеша с диска).
Но соглашусь, кроме самого переезда код ещё серьезно рефакторился в процессе (при той же функциональности). Опять же замена 7.4 на 8.0 тоже дал свой буст. Переезд длился целый год, за этот момент многое успело устареть в старом монолите.
А о чем конкретно из async php хотелось бы почитать?
Я как раз собираюсь подготовить серию статей по мотивам моего доклада с конференции про Swoole. Вот думаю куда смещать акцент - больше практических результатов или больше теории.
Это был сарказм?
Статья — сплошная вода. Все описанное это обычная рутина руководителя, никакого подвига и «бестпрактис» тут нет. То есть совет уволить 5 новчок и нанять 2х профи — много ума не нужно, но у автора явно не было такого кейса (с учетом, что там всего было 10чел), но тем не менее подается это так, как будто это пройденный личный опыт.
Ну и наконец, если такие были обязанности у руководителя, то чем же занимался тимлид в проекте в конце концов, педалил код?)
Вот это разогнались прямо перед фиче-фризом, RFC-пад какой-то.)
Чего только не предлагают, абы generics не пилить)
Но в целом весь тот «сахар» лишним не будет, лишь бы производительность не просела и обратной не совместимости не было большой, никто ж не заставляет юзать / переписывать код под восьмёрку.
Так как раз вот тут и должна JIT компиляция помочь? Тут же как раз про яйцо и курицу, JIT сейчас ничего не привносит, а дженерики наоборот привнесут даунгрейд производительности. Что первое внедрять? )
Темпы развития языка впечатляют. 10 лет развития от PHP5 то PHP7 версии и всего 5 лет (тьфу-тьфу) от PHP7 до PHP8 версии, причем за 5 лет было/будет сделано больше чем за предыдущие 10.
Конечно, всегда хочется большего (дженерики, асинхронность) но и без этого PHP это уже не язык для «домашних страниц»)
Я все таки не понял, что не так с wkhtmltopdf? Сишный демон зависает если процес больше минуты ждёт io? Тогда как нджинкс решает данную проблему? Тем что там готовый плагин компилится?)
Мы у себя как раз взяли wkhtmltopdf и сворганили на go обёртку микросервис для http api — https://github.com/opsway/documents работает как часы.
Да Swoole крутая штука, с корутинами и асинхронным io, было бы интересно впихнуть сравнение в этот бенчмарк.
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).
Та же что и у партии: запад...
Тоже давно следил за аналитикой у Подоляки, но стало видно как его субъективность преобладала над объективностью пару недель назад. Особенно заметно на последнем видео (уже кстати на рутубе) про Краматорск, когда он на основании всего лишь одного довода сделал однозначный вывод. А если посмотреть интерпретацию про те же события от Каца, там высказано несколько доводов (в противоположном направлении) и только тогда сделан вывод. Подоляка сознательно или нет (думаю все же не специально, а как защитный психологический механизм, став заинтересованной стороной своих обзоров), но перестал упускать/пропускать объективные факты.
openswoole по ощущениям (после отпочкования) начал быстрее развиваться и в более правильную сторону. Перешли на него. Но не факт что выбор правильный.) В целом разницы сейчас особо нет, пока они взаимозаменяемые плюс-минус (другой докер имидж сбилдил и готово), если не считать последних фич...
https://github.com/opsway/doctrine-dbal-swoole-pgsql-driver
https://github.com/opsway/doctrine-orm-swoole
Так а что вы пытались мерять с помощью newrelic? TTFB (время ответа бекенда)? Так это как из пушки по воробьям. Это надо делать другими инструментами (мы на текущий момент забираем эту статистику из nginx ingress который балансировщиком стоит на фронте и логирует upstream response time).
А как вы с ним работали? С коробки да, будет ерунда. С отключенными корутинами вот это решение подходит https://github.com/upscalesoftware/swoole-newrelic/blob/master/src/Apm/TransactionDecorator.php если с включенными - переделать его на запуск мидлвари под каждую из корутин, а не запросов.
Но на текущий момент мы не стали заморачиваться и отказались вообще от профайлера. (В пользу в будущем перейти на OpenTracing кастомную реализацию)
После того как все устаканилось, есть планы протестировать и буст от JIT, и вопрос мультиплексирования vs многопоточности. Благо это не сложно - отключить корутины и поднять очень много воркеров, это 2 параметра по сути.
Ещё скоро перейдем на 8.1, тоже потестим.
Насчёт роадранера или оптимизаций для fpm я поясню, решение про переход на swoole принималось в дополнение к другим факторам: на тот момент проекту исполнилось 5 лет (и я напомню что это самопис): за это время там накопилось очень много легаси (причем речь не про бизнес код, а про сторонние пакеты), все это мешало апгрейдам (на тот же 8.0), мешало применять бест практис.
То есть кроме Swoole, мы перешли на 8.0, убрали все легаси пакеты (доктрины, симфони, убрали старые zend framework пакеты), переделали структуру проекта по DDD канонам и перешли на мидлвари и хттп хендлеры (PSR стандарты).
Поэтому решение использовать Swoole вместо Roadrunner (на тот момент эта была ещё первая версия) была принята осознано для того чтобы из коробки получить асинхронное IO.
В планах в дополнение к JSON API попробовать gRPC и общение клиентов по Websocket'ам. И текущая архитектура к этому уже готова (то есть Swoole это даст из коробки).
Newrelic показывал что процессорное время тратилось на такие банальные вещи как композеровский автолоадинг (было около 400 пакетов), на доктриновскую гидрацию (из всего времени php эти 2 вещи 60% времени занимали) и только потом вся бизнес логика и сверху ещё IO (который при бустрапинге тоже был - например чтение файлов кеша с диска).
Но соглашусь, кроме самого переезда код ещё серьезно рефакторился в процессе (при той же функциональности). Опять же замена 7.4 на 8.0 тоже дал свой буст. Переезд длился целый год, за этот момент многое успело устареть в старом монолите.
Да, это в планах. В течении 1-2 месяца оформим код в композер пакет.
А о чем конкретно из async php хотелось бы почитать?
Я как раз собираюсь подготовить серию статей по мотивам моего доклада с конференции про Swoole. Вот думаю куда смещать акцент - больше практических результатов или больше теории.
Статья — сплошная вода. Все описанное это обычная рутина руководителя, никакого подвига и «бестпрактис» тут нет. То есть совет уволить 5 новчок и нанять 2х профи — много ума не нужно, но у автора явно не было такого кейса (с учетом, что там всего было 10чел), но тем не менее подается это так, как будто это пройденный личный опыт.
Ну и наконец, если такие были обязанности у руководителя, то чем же занимался тимлид в проекте в конце концов, педалил код?)
Чего только не предлагают, абы generics не пилить)
Но в целом весь тот «сахар» лишним не будет, лишь бы производительность не просела и обратной не совместимости не было большой, никто ж не заставляет юзать / переписывать код под восьмёрку.
Конечно, всегда хочется большего (дженерики, асинхронность) но и без этого PHP это уже не язык для «домашних страниц»)
Я все таки не понял, что не так с wkhtmltopdf? Сишный демон зависает если процес больше минуты ждёт io? Тогда как нджинкс решает данную проблему? Тем что там готовый плагин компилится?)
Мы у себя как раз взяли wkhtmltopdf и сворганили на go обёртку микросервис для http api — https://github.com/opsway/documents работает как часы.
Это callable? Вроде да. В чем подвох? а может это все же array? ))
Так вроде никто и не мешает:
Вот только мой бенчмарк FPM vs Swoole (zend-expressive hello world) показал скорость выше всего на 20% (1000RPS). Возможно это было связано с мощным i7 процом (4/8).