Комментарии 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 это даст из коробки).
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 тоже дал свой буст. Переезд длился целый год, за этот момент многое успело устареть в старом монолите.
была начата. В нашем случае это происходило рандомно и это было очень хорошо заметно, особенно по вкладке Errors, где на «endpoint A», был выкинут «EndpointBException», который встречается только на «endpoint B».
А как вы с ним работали? С коробки да, будет ерунда. С отключенными корутинами вот это решение подходит https://github.com/upscalesoftware/swoole-newrelic/blob/master/src/Apm/TransactionDecorator.php если с включенными - переделать его на запуск мидлвари под каждую из корутин, а не запросов.
Но на текущий момент мы не стали заморачиваться и отказались вообще от профайлера. (В пользу в будущем перейти на OpenTracing кастомную реализацию)
Сейчас мы скооперировались с разработчиками RR и родили плагин для RR, который из golang части позволяет мерить со 100% аккуратностью, это для нас стало значительным плюсом по сравнению со swoole, где всё в NR вроде выглядит хорошо, но полного доверия как то нет… :)
Есть возможность выложить драйвер для доктрины в опенсорс?
А какой свуле вы используете? который опен свуле (вроде как отпочковался ) или изначальный?
использую активно, вообще-то, уже в трех проектах.. такого варианта нет в опросе?)
PHP на стероидах: Swoole in production