FrankenPHP — один из самых обсуждаемых новых способов запускать PHP‑приложения: меньше слоёв, иной жизненный цикл воркеров и акцент на производительность. Но в продакшене у большинства по-прежнему доминирует связка «web server (Nginx/Apache) + php-fpm». Ниже — практичное сравнение: что меняется в архитектуре, деплое и мониторинге, где реально возможен выигрыш, а где важнее предсказуемость.
Коротко: что такое FrankenPHP и что такое PHP-FPM
PHP-FPM — отдельный менеджер процессов FastCGI. Веб‑сервер (обычно Nginx, иногда Apache) проксирует динамические запросы в FPM по сокету или TCP. Внутри FPM работает пул воркеров: каждый запрос выполняется как отдельный «прогон» PHP‑кода, и большинство состояний (кроме того, что держит сам процесс — OPcache, расширения и т. п.) не переживает границу запроса.
FrankenPHP — рантайм, который запускает PHP ближе к серверному процессу и предлагает режим worker mode. Идея проста: уменьшить накладные расходы на проксирование и (в worker mode) держать приложение прогретым в памяти между запросами, сокращая холодный старт и повторную инициализацию фреймворка.
Ключевой момент: FrankenPHP — не «магическая кнопка ускорения». Он меняет модель процесса, а значит меняются эксплуатационные привычки: деплой, перезагрузки, утечки памяти, прогрев кэшей, поведение клиентов БД/Redis и наблюдаемость.
Архитектура: где живёт PHP и кто управляет процессами
Классика: Nginx/Apache + PHP-FPM
Типовой поток запроса выглядит так:
- Клиент приходит в web server (TLS, HTTP/2, статика, сжатие, лимиты, базовые защитные заголовки).
- Динамика отправляется в
php-fpmпо FastCGI. php-fpmвыбирает воркер из пула и выполняет запрос.- Ответ возвращается в web server и затем клиенту.
Сильная сторона модели — разделение ролей. Веб‑сервер оптимизирован под сеть и статику, FPM — под управление воркерами. Можно независимо тюнить, разводить разные версии PHP, разные пулы под разные приложения, по-разному ограничивать ресурсы и политики рестарта.
Если вы активно используете Nginx/Apache как «фронт» (микрокеш, тонкий контроль заголовков, ограничения на загрузки), пригодится обзор отличий веб‑серверов: сравнение Nginx и Apache для продакшена.
FrankenPHP: меньше слоёв, другой жизненный цикл
В FrankenPHP PHP‑исполнение интегрируется в серверный процесс, а в worker mode запросы попадают в долгоживущий воркер, где приложение не пересоздаётся с нуля на каждый HTTP‑запрос. Это приближает PHP к модели application server (как у Node.js/Java), хотя типичный PHP‑код исторически заточен под «запрос‑ответ и забыли».
Отсюда компромисс: потенциально выше производительность за счёт прогретого приложения и меньших накладных расходов, но больше рисков долгоживущих процессов: накопление состояния, утечки памяти, «протухшие» соединения, неожиданные эффекты от глобальных синглтонов/статики.
Производительность: где FrankenPHP реально может выиграть
Скорость PHP‑приложения чаще упирается не в интерпретатор как таковой, а в суммарную стоимость «обвязки» вокруг бизнес‑логики:
- bootstrap фреймворка, автозагрузка, контейнер DI;
- операции с файловой системой (поиск классов, чтение конфигов);
- установление соединений (БД, Redis, внешние API);
- настройка и прогрев OPcache;
- конкуренция за CPU/память на пиках.
PHP-FPM: сильная сторона — предсказуемость
FPM хорош тем, что «плохое состояние» обычно не живёт долго. Даже если в коде есть мелкая утечка, процесс можно ограничить перезапуском по числу запросов через pm.max_requests. Это заметно снижает вероятность медленной деградации неделями.
OPcache в FPM тоже работает отлично: при корректной настройке вы не компилируете скрипты заново каждый раз, а «стоимость» FastCGI‑проксирования часто не становится главным узким местом.
FrankenPHP worker mode: сильная сторона — экономия на повторной инициализации
Если приложение тяжёлое на bootstrap (часто так бывает у больших Laravel/Symfony‑проектов), worker mode может уменьшить TTFB и сгладить пики, потому что:
- часть объектов и конфигурации остаётся в памяти между запросами;
- меньше повторных аллокаций и «холодных» путей;
- может быть ниже накладная стоимость связки web server ↔ PHP.
Сравнивайте только на одинаковой инфраструктуре и одинаковых лимитах CPU/RAM, с прогревом и снятием p95/p99. «Стало быстрее» без методики почти всегда превращается в спор ощущений.
Где выигрыша может не быть
Если основное время запроса уходит в базу данных, внешние API или тяжёлые вычисления, смена рантайма не даст кратного ускорения. Более того, при долгоживущих воркерах иногда проявляются «хвосты» латентности из‑за поведения памяти и накопления состояния.
Эксплуатация и деплой: что меняется в реальной жизни
Перезагрузки и безостановочный деплой
В FPM‑стеке вы обычно разделяете операции:
- reload веб‑сервера (конфиги, TLS, upstream’ы);
- reload/restart FPM (обновление кода, сброс воркеров, смена ini‑настроек).
Это удобно для классического deploy: выкладка кода, прогрев, плавный reload FPM, контроль количества воркеров. Для FrankenPHP важно заранее продумать эквивалентную стратегию: как именно обновляется код, когда и как перезапускаются воркеры, как обеспечивается откат и что будет с текущими запросами при ротации процесса.
Лимиты ресурсов и изоляция
С PHP‑FPM привычно ограничивать пулы: отдельный Unix‑сокет, отдельный пользователь, отдельные лимиты, отдельные параметры и политики. На серверах с несколькими сайтами/клиентами это часто решающий фактор: проще добиться предсказуемого соседства проектов.
FrankenPHP тоже можно эксплуатировать безопасно, но модель изоляции нужно продумать заранее: где заканчивается один проект и начинается другой, как разделяются лимиты, как предотвращается влияние «потёкшего» воркера одного приложения на остальные.
Практический совет: если вы хостите несколько проектов и хотите жёсткой изоляции по CPU/RAM и разным версиям окружения, чаще всего проще разнести приложения по отдельным виртуальным машинам или контейнерам. Для этого удобно использовать VDS, чтобы каждому сервису задать свои лимиты и политики рестартов.
Наблюдаемость: метрики и диагностика
У FPM богатая и привычная диагностика: status‑страница, slowlog, понятные метрики по пулам, типовая интеграция с мониторингом. Во многих командах это «общий язык» между админами и разработчиками.
С FrankenPHP многое зависит от того, какие инструменты вы используете вокруг. В продакшене вам потребуется заранее ответить на вопросы:
- как детектировать рост памяти у воркера и предотвращать OOM;
- как ловить деградацию после N запросов (а не только «сейчас медленно»);
- как измерять конкуренцию и очереди, если они появляются;
- какие события считать причиной рестарта воркера (деплой, порог памяти, таймауты, ошибки).
Риски worker mode: о чём забывают при первом внедрении
Неявное состояние между запросами
В классическом PHP вы часто не думаете о том, что глобальные переменные, статические свойства, синглтоны и кэши живут дольше запроса. В worker mode это становится реальностью. Любой баг с накоплением данных превращается в медленную деградацию: сначала всё быстро, потом растёт память, затем начинается своп или OOM.
Соединения и таймауты
Долгоживущий процесс чаще сталкивается с «протухшими» соединениями к базе данных или Redis (сетевые флапи, NAT, балансировщики, простои). В FPM часть подобных проблем смягчается более короткой жизнью воркера и плановыми перезапусками.
План рестартов как часть дизайна
Если вы выбираете worker mode, заложите рестарты как нормальную операцию: по времени, по числу запросов, по метрикам памяти, по событиям деплоя. Это не «костыль», а страховка для долгоживущих процессов.
Совместимость: Nginx/Apache, статика и фронтовые возможности
В классической схеме web server (Nginx/Apache) остаётся «фронтом»: он отлично умеет статику, кеширование, лимиты, сложные правила маршрутизации, защитные заголовки и другие вещи, которые критичны в продакшене.
Если вы опираетесь на фронтовую часть (например, тонко выставляете заголовки безопасности), держите под рукой чек‑лист и примеры: чек‑лист security headers для Nginx и Apache.
FrankenPHP может уменьшить количество компонентов, но вопрос не только в количестве процессов. Вопрос в том, какие возможности фронта вы используете и насколько они обязательны: микрокеш, сложные правила, ограничения на загрузки, интеграции с текущими модулями и политиками.
Практичные сценарии выбора
Когда почти наверняка лучше PHP-FPM
- Несколько сайтов/клиентов на одном сервере, нужна строгая изоляция пулами.
- Команда и поддержка уже «заточены» под FPM: диагностика, алерты, типовые инциденты.
- Проект чувствителен к стабильности и предсказуемости, а выигрыш от worker mode не подтверждён тестами.
- Вы активно используете возможности Nginx/Apache как фронта и не хотите менять слой маршрутизации.
Когда FrankenPHP особенно интересен
- Монолитное приложение с тяжёлым bootstrap, где важен TTFB и стабильная латентность.
- Есть время и дисциплина на нагрузочные тесты, мониторинг и план рестартов.
- Вы хотите упростить стек и готовы принять новый операционный профиль (долгоживущие воркеры).
- Вы контролируете кодовую базу и можете устранять проблемы со «состоянием между запросами».
Как сравнивать честно: минимальная методика бенчмарка
Чтобы сравнение FrankenPHP и PHP‑FPM было полезным, а не «про ощущения», достаточно базовой дисциплины:
- Одинаковое железо или виртуализация, одинаковые лимиты CPU/RAM.
- Одинаковая база и кэши, и отдельный тест без БД, чтобы понять «чистую» стоимость рантайма.
- Прогрев: холодный старт и прогретое состояние — два разных теста.
- Снимаем p95/p99, а не только среднее.
- Параллельно смотрим потребление памяти и частоту рестартов.
Обязательно фиксируйте настройки: версию PHP, включён ли OPcache, параметры пула/воркеров, таймауты на фронте, размер ответа, есть ли сессии.
Чек-лист миграции (если хочется попробовать FrankenPHP)
Если планируете пилот, начните с безопасного маршрута:
- Выберите один сервис с понятным профилем нагрузки.
- Заложите наблюдаемость: метрики по памяти/латентности/ошибкам, логи с корреляцией запросов.
- Опишите правила рестарта воркеров (по деплою, по памяти, по времени, по числу запросов).
- Проверьте код на неявное состояние: синглтоны, статические кэши, глобальные контейнеры.
- Прогоните нагрузку и сравните p95/p99, а также стабильность после длительного теста (1–2 часа).
Итог: что выбрать сегодня
PHP-FPM — «скучная», но очень сильная база: предсказуемый продакшен, привычная диагностика, понятный деплой, удобная изоляция. Если нужен надёжный web‑server‑стек и минимум сюрпризов — FPM остаётся дефолтным выбором.
FrankenPHP имеет смысл, когда вы готовы управлять жизненным циклом долгоживущих воркеров и хотите выжать дополнительную производительность за счёт worker mode. Но решение стоит принимать только после тестов и с планом эксплуатации (метрики, рестарты, деградация), а не «потому что модно».
