Хвост инженера

Автор: Александр Луценко · HighLoad Channel

Профиль показывает, где программа тратит процессорное время. Из этого легко сделать лишний вывод: если внутри обработчика всё быстро, то и пользователь должен получить быстрый ответ. В production между этими двумя утверждениями могут находиться очередь, исчерпанные воркеры, сеть и другие части системы, которые профилировщик кода не видит.

Александр Луценко рассказывает, как команда перенесла профилирование с dev-окружения в production и превратила его в постоянный observability-сигнал. Мотивация проста: stage отличается от production железом, данными и формой нагрузки. Даже хороший нагрузочный тест не воспроизводит все сочетания условий, которые возникают в реальной системе.

Для сбора команда выбрала sampling profiler в отдельном sidecar-контейнере. Он не требовал менять код приложения или устанавливать расширение внутрь процесса. Профили отправлялись в коллектор, фильтровались, агрегировались и дополнялись метками сервиса, окружения и транзакции. Так отдельный flame graph превращался в историю поведения приложения между релизами.

Но постоянный сбор не делает профилирование полной моделью запроса. В одном из примеров endpoint внутри приложения выполнялся за миллисекунды, тогда как внешние измерения показывали ответ до трёх секунд. Причиной оказался недостаток воркеров: запросы долго ждали очереди перед тем, как попасть в быстрый обработчик.

Кому смотреть: backend- и platform-командам, которые хотят профилировать production или уже собирают профили, но рассматривают их отдельно от метрик и distributed tracing.

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

Автор: Антон Титов (SpiralScout) · PHP Russia 2019

Классическая модель PHP начинает каждый запрос почти с чистого состояния: загружает приложение, создаёт контейнер и после отправки ответа освобождает процесс. RoadRunner сохраняет PHP worker между запросами — и тем самым превращает прежнюю гарантию очистки в ответственность разработчика.

Антон Титов показывает гибридную архитектуру, в которой сервер на Go принимает запросы и управляет долгоживущими PHP-процессами. Приложение не нужно загружать заново для каждого обращения, поэтому уменьшается стоимость инициализации. На уровне HTTP автор заявляет ускорение примерно в двадцать раз, хотя такой результат относится к конкретному benchmark, а не к любому PHP-проекту.

У производительности есть обратная сторона. Объект, соединение или пользовательский контекст теперь способны пережить запрос, для которого были созданы. PHP-приложение должно работать как настоящий долгоживущий сервис, а не рассчитывать, что процесс автоматически уничтожит всё состояние.

Кому смотреть: PHP-разработчикам, которые рассматривают RoadRunner, FrankenPHP или другую модель долгоживущих workers.

Из этого можно взять в работу: проверить сервисы и singleton-объекты приложения на данные текущего пользователя, запроса или транзакции, которые могут остаться в памяти после ответа.

Автор: Ильяс Салихов (retailCRM) · PHP Russia 2019

Язык с быстрым runtime не обязательно делает разработку сервиса дешевле. Если приложению нужны сотни полей, сложная валидация, связи между сущностями и миграции, стоимость готовых прикладных абстракций может оказаться важнее производительности самого языка.

Ильяс Салихов сравнивает PHP и Go на опыте retailCRM. На момент доклада систему обслуживали около тридцати сервисов: примерно 60% были написаны на PHP с Symfony, 30% — на Go. Автор не выбирает победителя, а показывает задачи, для которых в компании использовали каждый стек.

PHP выигрывал в насыщенных бизнес-приложениях. Symfony и Doctrine давали ORM, Unit of Work, миграции, формы и валидацию. Go выбирали для небольших API и сервисов с конкурентной обработкой, где были полезны goroutines, производительность и поставка одним бинарником.

Кому смотреть: тимлидам и backend-разработчикам, которые выбирают язык для нового сервиса внутри уже работающей системы.

Из этого можно взять в работу: сравнивать не только скорость runtime, но и список инфраструктурных и прикладных механизмов, которые команде придётся реализовать или сопровождать самостоятельно.

Автор: Дмитрий Стогов (Zend Technologies) · PHP Russia 2019

⚠️ Доклад 2019 года — за год до выхода PHP 8.0 (ноябрь 2020). Это анонс и технический разбор того, что готовилось. JIT, Preloading и FFI с тех пор вышли в стабильных версиях; суть механизмов Стогов объясняет точнее, чем большинство статей, написанных постфактум.

Дмитрий Стогов — один из ключевых людей за производительностью PHP. Автор Turck MMCache (eAccelerator), мейнтейнер Zend OPcache, лидер проекта PHPNG, который лёг в основу PHP 7 и дал двукратный прирост производительности без изменения синтаксиса. Теперь — лидер разработки JIT-компилятора для PHP 8. Когда он рассказывает о производительности PHP — это рассказ от человека, который её делал.

Три новых подсистемы PHP 8 — JIT, Preloading и FFI — Стогов рассматривает как взаимосвязанные. Все три направлены на производительность, но также открывают PHP новые области применения: писать системно-зависимые расширения прямо на PHP, подключать сторонние C-библиотеки, быстро прототипировать низкоуровневые вещи.

Кому смотреть: PHP-разработчикам, которые хотят понять JIT, FFI и Preloading не через «что делать в коде», а через «как это устроено и зачем» — от человека, который это написал.

Из этого можно взять в работу: если ваш PHP-сервис тяжело нагружен CPU-вычислениями (а не I/O) — именно для таких сценариев JIT даёт реальный прирост. Для типичного CRUD с базой данных эффект от JIT минимален — и Стогов об этом говорит честно.

Автор: Валентин Удальцов (Happy Inc. / Typhoon) · PHP Russia 2021

Валентин Удальцов в Happy Inc. прошёл полный путь от ORM до нативного SQL — и рассказывает об этом не как об отказе от абстракций ради принципа, а как об архитектурном решении, которое «во всех смыслах выгодно». Отправная точка: ORM, QueryBuilder и прочие абстракции связывают руки при попытке использовать базу данных на полную.

Конкретный вопрос, который задаёт Удальцов: какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции? Если абстракция закрывает доступ к возможностям СУБД, которую вы выбрали — это уже не абстракция, это ограничение.

Кому смотреть: PHP-разработчикам, которые чувствуют что ORM начинает ограничивать — но не решаются отказаться от него, потому что «так принято».

Из этого можно взять в работу: найти в своём проекте одно место где вы написали сложный raw SQL внутри ORM-контекста (через DB::raw() или аналог). Если такое место есть — это сигнал, где абстракция уже не помогает.