Pull to refresh

Comments 16

По большому счету прирост вы получили не из-за асинхронности и swoole, а из-за выбрасывания тяжелого бутстрапа. Заплатив за это ровно ту стоимость, скидку на которую дает "умирающий" пхп.

Ну и совсем немного экономии на переключении контекста процессора, если бы у вас было бы 70 однопоточных воркеров (например, с тем же роадранером, или какой-то свой менеджер соединений).

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

Но при этом не раскрыта полостью тема сокращения времени бутстрапа более крассическими методами - кеш, прелоадинг, рекомендации Symfony. 120 ms намекает, что там еще большой простор.

Могу пованговать, но скорее всего от роадраннера они получили бы такой же профит, но при значительно меньших трудозатратах.

После того как все устаканилось, есть планы протестировать и буст от 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 это даст из коробки).

Могу поделиться своим опытом. Был проект на Phalcon, решили двигаться в сторону Swoole. Медленно перешли на Laminas/mezzio. Медленно т.к. пришлось значительно переделать проект под то, чтобы понимать, что мы оставляем в памяти. Зарелизили swoole на продакшен — выявились проблемы с APM (newrelic), решили что буст по перфомансу не стоит некачественной APM информации. Вернулись в phpfpm. Сейчас пытаемся в Roadrunnner, доработки проекта, за исключением кастомного worker.php из документации не потребовалось вообще — работает из коробки. RR показывает значительный прирост по большинству endpoint, но не на всех, на текущий момент изучаем, что именно тормозит.

Swoole еще не понравился довольно скудной документацией и тем, что шаг вправо, шаг влево — китайская дока.
Для осознаний масштаба, размер базы данных postgresql >250Гб (с индексами)

ну 250гб это не много, у нас в марии 8тб лежат, есть таблица весом 45гб с индексом на неё 50гб. и даже это как-то язык не поворачивается назвать масштабом.

Раньше «бутстрап» нашего аппа занимал более 120мс

это очень странные показатели. такое ощущение что это без опкеша вообще.

Некоторый выгрыш, например, мы получили тем, что убрали хранение кеша для доктрины из редиса внутрь shared in memory хранилице для всего пода — тем самым снизили накладные расходы на сетевую задержку.

ну это можно было и в php-fpm сделать, через тот же shmop. может у вас там редис был в другом полушарии с каналом 1мбит и весь выигрыш случился из-за этого.

в общем да, сложно о чем-то судить. такое ощущение что оптимизацией не занимались вообще, будто крутился php-fpm, где в дефолтных конфигах поменяли только количество воркеров.
описание утилизации ресурсов до переезда на swoole выглядит так, будто вы там Множество Мандельброта считали на каждый запрос.

Newrelic показывал что процессорное время тратилось на такие банальные вещи как композеровский автолоадинг (было около 400 пакетов), на доктриновскую гидрацию (из всего времени php эти 2 вещи 60% времени занимали) и только потом вся бизнес логика и сверху ещё IO (который при бустрапинге тоже был - например чтение файлов кеша с диска).

Но соглашусь, кроме самого переезда код ещё серьезно рефакторился в процессе (при той же функциональности). Опять же замена 7.4 на 8.0 тоже дал свой буст. Переезд длился целый год, за этот момент многое успело устареть в старом монолите.

Увидел что вы используете newrelic и swoole и очень удивлен — в таком режиме он ведь не может гарантировать, что в рамках одного request будет завершена та же транзакция, что и
была начата. В нашем случае это происходило рандомно и это было очень хорошо заметно, особенно по вкладке Errors, где на «endpoint A», был выкинут «EndpointBException», который встречается только на «endpoint B».

А как вы с ним работали? С коробки да, будет ерунда. С отключенными корутинами вот это решение подходит https://github.com/upscalesoftware/swoole-newrelic/blob/master/src/Apm/TransactionDecorator.php если с включенными - переделать его на запуск мидлвари под каждую из корутин, а не запросов.

Но на текущий момент мы не стали заморачиваться и отказались вообще от профайлера. (В пользу в будущем перейти на OpenTracing кастомную реализацию)

Да, с этим пакетом было получше, но все равно некорректная информация проскакивала регулярно. Например на staging можно было наблюдать транзакции по 150 секунд. Кто-то начинал транзакцию, но она не заканчивалась, пока кто-то еще не присылал request. Под нагрузкой было не заметно, но осадок остается — как после такого данным верить?

Сейчас мы скооперировались с разработчиками RR и родили плагин для RR, который из golang части позволяет мерить со 100% аккуратностью, это для нас стало значительным плюсом по сравнению со swoole, где всё в NR вроде выглядит хорошо, но полного доверия как то нет… :)

Так а что вы пытались мерять с помощью newrelic? TTFB (время ответа бекенда)? Так это как из пушки по воробьям. Это надо делать другими инструментами (мы на текущий момент забираем эту статистику из nginx ingress который балансировщиком стоит на фронте и логирует upstream response time).

Есть возможность выложить драйвер для доктрины в опенсорс?

Да, это в планах. В течении 1-2 месяца оформим код в композер пакет.

А какой свуле вы используете? который опен свуле (вроде как отпочковался ) или изначальный?

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

использую активно, вообще-то, уже в трех проектах.. такого варианта нет в опросе?)

Sign up to leave a comment.

Articles