Когда речь заходит о современном PHP на VDS, спор обычно выглядит так: оставить классический Nginx + PHP-FPM, перейти на Nginx Unit или попробовать RoadRunner ради меньшей задержки и долгоживущих воркеров. На практике это не вопрос «что быстрее в синтетике», а вопрос эксплуатационной модели.
Один и тот же проект может отлично жить на PHP-FPM, спорно чувствовать себя на Unit и очень быстро работать на RoadRunner, но только если команда понимает, как устроен жизненный цикл приложения. Для администратора это не теория: от выбранной модели зависят деплой, лимиты памяти, перезапуски, диагностика и сценарий отката.
В 2026 году выбор особенно важен, потому что сами PHP-приложения стали тяжелее. Laravel, Symfony, middleware, очереди, трейсинг, контейнер зависимостей, клиенты Redis и HTTP — всё это увеличивает цену каждого cold start. Поэтому модель «каждый запрос стартует заново» уже не всегда оптимальна.
Но и долгоживущие воркеры не бесплатны. Вместе с ускорением приходят риски утечек памяти, stale state, сложность graceful reload и более дорогая диагностика. Ниже разберём три подхода без фанатизма: где PHP-FPM по-прежнему лучший выбор, где Nginx Unit оправдан архитектурно, а где RoadRunner действительно приносит пользу.
Три модели выполнения PHP и почему это важно
Снаружи все три варианта могут обслуживать один и тот же HTTP-трафик. Разница — внутри, в жизненном цикле запроса и процесса.
PHP-FPM: проверенная классика
PHP-FPM — это менеджер пула worker-процессов, к которым веб-сервер передаёт FastCGI-запросы. Обычно это связка Nginx + PHP-FPM. Каждый запрос обрабатывается в относительно чистом окружении: код выполняется, состояние сбрасывается, воркер возвращается в пул.
Главный плюс такого подхода — предсказуемость. Почти все PHP-приложения, CMS, пакеты и привычки экосистемы изначально рассчитаны именно на него. Есть slowlog, status page, зрелые практики по настройке pm, понятная модель ограничения ресурсов и простой rollback.
Минус тоже очевиден: инициализация приложения стоит времени. Да, opcache снимает часть накладных расходов, но bootstrap фреймворка, контейнер зависимостей, конфигурация и часть пользовательского кода всё равно выполняются на каждый запрос. На маленьком сервере это может быть терпимо, а на API с высокой RPS — уже заметно.
Nginx Unit: сервер приложений с единой конфигурацией
Nginx Unit — это отдельный application server, который сам принимает HTTP и умеет запускать приложения на разных языках, включая PHP. Для PHP это означает, что внешний Nginx не всегда обязателен, хотя в продакшене его нередко ставят перед Unit ради TLS, отдачи статики, лимитов и привычной edge-конфигурации.
Сильная сторона Unit — централизованная модель управления приложениями через API конфигурации. Можно описывать listeners, routes, applications и процессы в одном месте и применять изменения без классического reload всего стека. Для self-hosted платформы это бывает удобно: меньше разрозненных компонентов и меньше glue-логики.
Но Unit так и не стал стандартом де-факто для PHP. Причина не в том, что он плохой, а в том, что он занимает промежуточное положение: интереснее голого FPM по модели управления, но обычно не даёт такого выигрыша по execution model, как RoadRunner.
RoadRunner: долгоживущие воркеры
RoadRunner держит пул долгоживущих PHP worker-процессов. Приложение инициализируется один раз, после чего воркер обслуживает много запросов подряд. Именно это убирает значительную часть overhead, связанного с повторным bootstrap.
Отсюда и главный плюс: лучше latency на горячем приложении, выше throughput на CPU-ограниченных сценариях и меньше повторной работы на каждом запросе. Особенно хорошо это видно на JSON API, тяжёлых Laravel-проектах и сервисах, где критичен tail latency.
Но вместе с ускорением приходит новая дисциплина разработки. Всё, что раньше безопасно исчезало после завершения запроса, теперь может остаться в памяти воркера. Статические свойства, singleton-состояние, кэш в пользовательском коде, неочищенные ссылки и побочные эффекты начинают влиять на следующие запросы.
Что изменилось к 2026 году
Если несколько лет назад long-running PHP воспринимался как нишевая оптимизация для энтузиастов, то к 2026 году подход стал заметно спокойнее и прагматичнее. Многие команды уже попробовали его на staging и поняли две вещи: прирост действительно бывает ощутимым, но он не бесплатный.
Одновременно PHP-FPM никуда не делся и точно не «устарел». Для огромного числа продакшен-проектов это до сих пор лучший baseline: зрелый стек, понятный rollback, простая совместимость с любыми пакетами и удобная диагностика на малых и средних серверах.
Nginx Unit остаётся выбором для тех, кому нравится идея application server с централизованной конфигурацией и более целостной платформенной моделью. Но массового вытеснения PHP-FPM не произошло, и это важно: у FPM всё ещё шире экосистема, больше готовых рецептов и выше предсказуемость эксплуатации.
Короткий вывод заранее: по умолчанию выбирайте PHP-FPM, для Laravel и API с хорошей инженерной дисциплиной смотрите в сторону RoadRunner, а Nginx Unit рассматривайте как осознанный инфраструктурный выбор, а не как универсальный апгрейд производительности.
Сравнение по ключевым критериям
Производительность и задержка
В прямом сравнении RoadRunner чаще выигрывает по средней и особенно по хвостовой задержке на прогретом приложении. Причина проста: меньше повторного bootstrap. Для API, где на каждый запрос приходится немного I/O и довольно много framework overhead, это даёт заметный эффект.
PHP-FPM может показывать очень достойный результат, если грамотно настроены pm, opcache и сам bootstrap приложения. Но при одинаковом коде FPM обычно проигрывает там, где цена старта запроса значительна.
Unit в вопросе raw performance редко становится безоговорочным лидером. Он может быть конкурентным, но чаще его выбирают не за рекордные бенчмарки, а за operational model и удобство платформенного управления.
Потребление памяти
С памятью всё менее очевидно, чем кажется. Долгоживущие воркеры действительно экономят часть CPU на повторных стартах, но memory footprint у RoadRunner может как улучшиться, так и ухудшиться. Если приложение аккуратное, без удержания лишних объектов, результат хороший. Если нет — воркеры постепенно распухают.
У PHP-FPM память предсказуемее. Модель с pm.max_requests и полным завершением процесса давно отработана. Поэтому на небольшом сервере FPM часто комфортнее: проще посчитать верхнюю границу RAM и меньше сюрпризов после релиза.
Unit обычно тоже ведёт себя стабильно, но профиль памяти зависит от числа процессов и реальной тяжести приложения. Магии здесь нет: если код тяжёлый, память всё равно понадобится.
Совместимость с приложениями и библиотеками
По совместимости победитель почти всегда PHP-FPM. Он максимально близок к тому, как проект «ожидает» работать. Большинство CMS, самописных приложений и типовых PHP-сервисов просто запускаются и живут без дополнительных оговорок.
RoadRunner требует проверки на безопасность long-running модели. Нужно ревизовать жизненный цикл сервисов, статическое состояние, обработку исключений, request-scoped зависимости, кэш в памяти и повторное использование соединений. Для Laravel это уже нормальная практика, но «поддерживается» не означает «можно включить и забыть».
Unit с точки зрения обычного PHP-приложения довольно дружелюбен, но у него меньше накопленного operational-опыта в сообществе. Если у вас нестандартный edge case, шанс быстро найти проверенный рецепт ниже, чем для FPM.
Простота эксплуатации на VDS
Для администратора PHP-FPM — самый понятный и дешёвый по cognitive load вариант. Всё прозрачно: Nginx проксирует в Unix socket, есть отдельные пулы, лимиты, reload, логирование, systemd-unit и привычная диагностика через ss, journalctl, top и strace.
RoadRunner добавляет новый слой рантайма. Нужно следить за worker pool, health checks, лимитами по памяти, graceful shutdown и корректным деплоем без потери запросов. Это не запредельно сложно, но уже требует инженерной зрелости и наблюдаемости.
Unit удобно администрировать там, где команде нравится API-driven управление и декларативная конфигурация. Но по числу специалистов, которые умеют дебажить его «на автомате», он пока уступает PHP-FPM.
Когда выбирать PHP-FPM
Несмотря на популярность application server-подходов, PHP-FPM остаётся правильным ответом в большинстве типовых случаев.
- У вас обычный сайт, CRM, интернет-магазин, CMS или корпоративное приложение без экстремальной нагрузки.
- Важнее надёжность и простой rollback, чем максимальная производительность на одно ядро.
- Команда не хочет инвестировать время в аудит long-running поведения кода.
- Сервер небольшой, а память и операционная простота важнее модных архитектур.
- Нужна максимальная совместимость с расширениями, пакетами и привычными практиками поддержки.
Важно подчеркнуть: грамотно настроенный FPM — это не компромисс, а зрелое продакшен-решение. Очень часто проблему производительности решают не сменой рантайма, а устранением медленных SQL, нормальным кэшем, настройкой opcache и уменьшением лишней работы в bootstrap.
Когда выбирать RoadRunner
RoadRunner имеет смысл там, где вам действительно нужен выигрыш от долгоживущих воркеров, а команда готова поддерживать такую модель.
- Высоконагруженные JSON API и backend-for-frontend сервисы.
- Laravel-проекты с тяжёлым bootstrap, где важен low latency.
- Сервисы с большим количеством однотипных коротких запросов.
- Проекты, где уже есть культура нагрузочного тестирования и memory profiling.
- Команды, которые готовы следить за lifecycle приложения, а не только за Nginx и
php.ini.
Для Laravel выбор в пользу RoadRunner особенно логичен, когда приложение уже упирается в CPU из-за постоянной инициализации фреймворка. Но перед миграцией полезно честно ответить на вопрос: вы уверены, что bottleneck именно в модели исполнения, а не в базе данных, Redis, файловой системе или внешних API?
Если у вас в стеке есть фоновые обработчики и очереди, сначала полезно навести порядок в процессах и перезапусках — на практике помогает подход из статьи про настройку очередей, Supervisor и systemd для воркеров. Без этого long-running модель часто начинает болеть не в вебе, а в обслуживающих процессах.
Когда выбирать Nginx Unit
Сценарий выбора Unit уже, но вполне реальный.
- Вам нужен application server с конфигурацией, управляемой через API.
- Хочется уменьшить количество разрозненных компонентов в self-hosted стеке.
- Есть несколько приложений или сервисов, которыми удобно управлять централизованно.
- Команду устраивает менее массовый, но архитектурно аккуратный инструмент.
Если вы рассматриваете Unit как «замену FPM, которая точно даст ускорение», ожидания лучше снизить. Если рассматриваете его как платформенное решение с другой моделью конфигурации и процессов — это уже честная постановка задачи.
Практика для VDS: что реально важно кроме выбора сервера приложений
В запросах о сравнении PHP application server слишком много внимания обычно уделяют только рантайму. Но на сервере итоговое поведение почти всегда определяется совокупностью факторов, а не одной модной технологией.
CPU и планировщик
RoadRunner лучше раскрывается, когда CPU не забит соседними задачами и у вас достаточно ядер или хотя бы предсказуемая квота. Если сервер совсем маленький, а утилизация упирается в одно-два ядра, эффект может оказаться скромнее ожиданий.
Память и лимиты
Для FPM важно считать число воркеров по реальному RSS, а не по чужой таблице. Для RoadRunner — контролировать memory growth и лимиты рестарта. Для Unit — помнить, что уменьшение числа компонентов не отменяет цену самого приложения.
OPcache
opcache нужен во всех трёх сценариях. С ним FPM становится заметно быстрее, Unit тоже выигрывает, а в RoadRunner он остаётся актуальным, потому что код всё равно исполняется интерпретатором PHP. Но сам по себе OPcache не превращает request-per-request модель в long-running.
Релизы и graceful restart
На FPM схема деплоя обычно проще: выкладка, reload, прогрев, переключение symlink при необходимости. С RoadRunner важно отдельно проверить graceful draining воркеров и поведение во время rolling restart. Если планируете такие обновления на бою, заранее прогоните сценарий без простоя по шагам, как в материале про миграцию сайта без даунтайма.
Наблюдаемость
Если вы не видите p95, p99, memory drift, число активных воркеров, частоту рестартов и ошибки приложения, то выбирать по бенчмаркам бессмысленно. Особенно это касается RoadRunner: без метрик long-running стек быстро превращается в гадание.
Минимальные ориентиры по конфигурации
Ниже не готовые production-рецепты, а скорее sane baseline, от которого удобно стартовать и дальше проверять цифрами.
PHP-FPM: что проверить первым
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 1000
request_terminate_timeout = 60sДальше эти значения нужно сверять не с блогом, а с реальным RSS воркера, профилем нагрузки и временем ответа. Для небольшого сервера ошибка в pm.max_children болезненнее, чем выбор между Unit и FPM.
OPcache: базовый baseline
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=50000
opcache.validate_timestamps=1
opcache.revalidate_freq=2Если релизы атомарные и процесс деплоя контролируемый, параметры можно ужесточать, но только понимая последствия. Неудачная настройка инвалидирования кэша иногда ломает прод не хуже, чем нехватка CPU.
RoadRunner: что важно концептуально
workers.pool.num_workers = 8
workers.pool.max_jobs = 1000
workers.pool.supervisor.max_worker_memory = 256
http.pool.num_workers = 8Ключевая идея — ограничивать срок жизни воркера не только по ошибкам, но и по числу запросов и памяти. Это помогает бороться с накоплением состояния и утечками. Значения подбираются только нагрузочным тестом.
Частые ошибки при миграции
- Считать, что RoadRunner автоматически ускорит любой PHP-проект без изменений в коде.
- Сравнивать FPM и RoadRunner без одинакового прогрева OPcache и без реалистичной базы данных.
- Игнорировать memory leak и state leak в long-running воркерах.
- Выбирать Unit только потому, что в названии есть Nginx, ожидая идентичного operational experience.
- Оценивать стек по среднему времени ответа, не глядя на p95 и p99.
- Мигрировать в прод без сценария отката на классический PHP-FPM.
Итоговый выбор без религиозных войн
Если нужен короткий практический вывод для продакшена на сервере, он выглядит так: PHP-FPM — лучший default. Это самый сбалансированный вариант для большинства сайтов и приложений: совместимый, предсказуемый, хорошо документированный и дешёвый в сопровождении.
RoadRunner — выбор для тех, кто действительно понимает, зачем ему долгоживущие воркеры. На API и Laravel-проектах он может дать отличный результат, но только при взрослой дисциплине разработки и эксплуатации.
Nginx Unit — не экзотика и не «убийца FPM», а отдельный тип инструмента. Он хорош там, где важна его модель управления приложениями и конфигурацией. Но как универсальный ответ на вопрос «что лучше для PHP» подходит не всегда.
Поэтому для self-hosted PHP на VDS я бы советовал идти от простого к сложному: сначала выжать максимум из PHP-FPM и OPcache, затем подтвердить профилированием, что bottleneck именно в request lifecycle, и только после этого тестировать RoadRunner. Unit стоит брать тогда, когда вам действительно нужна его платформа, а не просто надежда на магическое ускорение.
И да, в 2026 году зрелость решения всё ещё важнее модности. Самый быстрый стек на бумаге легко проигрывает чуть менее быстрым, но понятным и наблюдаемым системам в реальной эксплуатации.
