PHP‑режимы исполнения: CGI, FastCGI, PHP‑FPM и LSAPI на виртуальном хостинге

На виртуальном хостинге от выбора «режима» исполнения PHP часто зависит почти всё: скорость первого байта, устойчивость к пикам трафика, предсказуемость использования памяти, изоляция между аккаунтами и даже способ, которым вы можете настраивать php.ini. Этот обзор — практическая шпаргалка для админов, девопсов и вебмастеров: что такое CGI, FastCGI, PHP‑FPM и LSAPI, чем они различаются и что выбрать именно вам.

Зачем вообще нужны разные «режимы PHP»

«Режим PHP» — это способ интеграции интерпретатора PHP с веб‑сервером: Apache, Nginx, LiteSpeed, OpenLiteSpeed и т. д. От связки зависит жизненный цикл процесса, кэширование байткода (opcache), реакция на перегрузки, изоляция и набор доступных директив. Правильный выбор даёт заметный выигрыш не только в RPS и TTFB, но и в стабильности при ошибках приложения, миграциях и обновлениях.

Главная идея эволюции: уйти от «одноразового» запуска интерпретатора (CGI) к «долгоживущим» пулам воркеров (FastCGI, FPM, LSAPI) с общим opcache и предсказуемым управлением ресурсами.

CGI: исторический минимум

Классический CGI запускает отдельный процесс PHP на каждый HTTP‑запрос. Это просто и совместимо, но крайне неэффективно: высокий накладной расход на форк/инициализацию, отсутствует общий opcache между запросами, нет контроля пула воркеров. На практике это означает медленный TTFB на каждом хите и непредсказуемую задержку под нагрузкой.

Плюсы CGI на бумаге: простота, изоляция на уровне процесса, отсутствие долгоживущих демонов. Минусы — всё остальное. В мире виртуального хостинга CGI сегодня встречается либо как fallback для экзотических сценариев совместимости, либо из соображений исторического наследия. Для продакшена и CMS его стоит избегать.

FastCGI: постоянный процесс вместо форка на каждый запрос

FastCGI появилось как ответ на проблемы CGI: вместо бесконечных форков поднимается пул процессов интерпретатора, к которым обратится веб‑сервер. Это радикально сокращает накладные расходы и открывает путь к opcache. Рабочие варианты: Apache с mod_fcgid или mod_proxy_fcgi, Nginx с fastcgi_pass, а также старые схемы со spawn-fcgi.

Сильные стороны: производительность, устойчивость, гибкость таймаутов и буферов на стороне веб‑сервера. Слабые — управление пулами не настолько удобное, как в FPM; мониторинг и трейсинг сложнее «из коробки». На современном шаред‑хостинге FastCGI чаще выступает как транспорт до FPM‑пула, а не самостоятельная цель.

PHP‑FPM: стандарт де‑факто

PHP‑FPM (FastCGI Process Manager) — штатный менеджер процессов PHP, пришедший на смену кустарным схемам. Он запускается один раз, поднимает пулы воркеров (по одному или несколько на пользователя/сайт), и веб‑сервер отдаёт запросы в соответствующий сокет/порт.

Ключевые преимущества:

• Пулы процессов с отдельными лимитами и пользователями: изоляция по uid/gid, зачастую вкупе с chroot/namespace или LVE.
• Режимы планирования: pm = dynamic, ondemand, static — можно подобрать под профиль трафика.
• Опкеш на пул: общий кеш байткода для всех воркеров пула, быстрый холодный старт после прогрева.
• Диагностика: статус‑страница, slowlog, счётчики занятости воркеров, количество активных/свободных процессов.

На виртуальном хостинге FPM обычно означает: у каждого аккаунта свой пул, свой сокет, свои лимиты по количеству детей (pm.max_children) и памяти. Вы выигрываете в стабильности и предсказуемости, а провайдер — в контроле над шумными «соседями».

LSAPI/lsphp: подход LiteSpeed

LSAPI — специализированный интерфейс от LiteSpeed для общения веб‑сервера с PHP. В реальности вы чаще встретите бинарь lsphp, который совместим с PHP‑расширениями и управляется ядром веб‑сервера LiteSpeed/OpenLiteSpeed. Идея похожа на FPM, но интеграция глубже: LiteSpeed управляет жизненным циклом воркеров, очередями и грациозными перезапусками.

Сильные стороны LSAPI на шаред‑хостинге: высокая эффективность под смешанными нагрузками «много мелких запросов», тесная интеграция с .htaccess и правилами переписывания, хорошая совместимость с популярными CMS, экономное потребление памяти на один активный сайт. Плюс — встроенные механизмы защиты от перегрузки и HTTP/2/3 на уровне веб‑сервера LiteSpeed.

Из нюансов: LSAPI — часть экосистемы LiteSpeed, поэтому поведение и точки настройки отличаются от FPM. Для админа это обычно «работает из коробки», но тонкая отладка потребует знания терминов из мира LiteSpeed и панелей, которые его используют.

Сравнение по критериям, важным для виртуального хостинга

Производительность и задержки

• CGI: самый медленный из‑за постоянной инициализации интерпретатора и невозможности разделять opcache.
• FastCGI: быстрый, но без встроенного менеджера процессов; эффективность зависит от внешней обвязки.
• PHP‑FPM: стабильно высокая производительность, гибкий контроль пула и хорошие метрики.
• LSAPI: сравнимая или выше, чем FPM, особенно на пёстрых нагрузках; выгоду даёт глубина интеграции с LiteSpeed.

Память и устойчивость к пикам

• CGI: нет пула, память расходуется «на каждый запуск», пиковая нагрузка быстро превращается в лавину форков.
• FastCGI/FPM/LSAPI: ограничение по числу воркеров и очередям позволяет переживать пики без краха всей площадки.

Изоляция и безопасность

• CGI: изоляция процедурная, но часто без современных механизмов ограничения.
• FPM: отдельный пользователь/пул, чёткие границы, совместимо с chroot/LVE, удобно ограничивать ресурсы.
• LSAPI: аналогично, при использовании LiteSpeed и LVE даёт строгую изоляцию.

Совместимость и настройка

• CGI: минимум возможностей локальной настройки; многие директивы не применишь через .htaccess.
• FPM: настройки через .user.ini и панель хостинга; часть директив закреплена как php_admin_value на стороне провайдера.
• LSAPI: хорошая поддержка .htaccess и привычных для Apache правил; поведение предсказуемо для популярных CMS. Если выбираете фронтенд‑веб‑сервер — пригодится сравнение Nginx и Apache.

Что выбрать на виртуальном хостинге

Если у провайдера доступен выбор, практичная матрица такая:

• Небольшие сайты, лендинги, блог на WordPress: FPM или LSAPI. Разницы «на глаз» не заметите, важнее корректные лимиты и opkеш.
• Магазины и CRM с пиковыми нагрузками: FPM с продуманным pm и таймаутами, либо LSAPI, если площадка на LiteSpeed и активно пользуется кешированием.
• Наследие или специфическая совместимость: только если вынуждены — CGI, но планируйте миграцию.

Если сайт «упирается» в лимиты пула (очереди растут, 502/504 множатся), а оптимизации на уровне кода и кэшей уже проведены — настал момент рассмотреть выделенные ресурсы. На виртуальном хостинге вы ограничены общими правилами площадки; собственный пул на выделенной среде даст большую предсказуемость. Начать проще на тарифах виртуального хостинга, а затем мигрировать при росте.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Таймауты и лимиты: где смотреть и что согласовывать

Большинство «загадочных» 502/504 — это не «сломался PHP», а несогласованные таймауты и буферы между веб‑сервером и пулом. На что обращать внимание:

• Лимиты PHP: max_execution_time, memory_limit, post_max_size, upload_max_filesize, max_input_vars. Часть можно менять через .user.ini.
• FPM: pm, pm.max_children, pm.max_requests, request_terminate_timeout, catch_workers_output. На шаред‑хостинге эти параметры задаёт провайдер, но уточнить текущие значения полезно.
• Nginx: fastcgi_read_timeout, fastcgi_connect_timeout, fastcgi_send_timeout, fastcgi_buffers, client_max_body_size.
• Apache mod_proxy_fcgi или mod_fcgid: ProxyTimeout, Timeout, FcgidIOTimeout, FcgidBusyTimeout.

Типичный сигнал узкого места — заполнение очереди в пуле и рост времени ожидания ответа при стабильной загрузке CPU. Это повод увеличить pm.max_children или оптимизировать приложения: сократить блокирующие операции, включить кэширование, разгрузить тяжёлые задачи в очередь.

Opcache: реальная половина производительности

Без opcache PHP вынужден повторно парсить и компилировать скрипты. В FPM/LSAPI общий opcache на пул существенно сокращает задержки после «прогрева». На что смотреть:

• opcache.enable: должен быть включён.
• opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files: достаточно ли памяти и слотов для вашего кода.
• opcache.validate_timestamps и opcache.revalidate_freq: баланс актуальности и производительности; для разработки — чаще проверять, для продакшена — реже.

На виртуальном хостинге перезапуск пула обычно недоступен пользователю. Для инвалидации кэша используйте инструменты CMS или расширения, вызывающие opcache_reset(), либо дождитесь естественной переинициализации при грациозном рестарте пула.

Безопасность и изоляция на шаред‑площадке

Классический open_basedir давно не считается полноценной изоляцией. Ключ — запуск каждого сайта под своим пользователем, отдельный пул, ограничения на системном уровне (cgroups/namespace/LVE), грамотные права на сокеты и каталоги. В этом смысле FPM и LSAPI дают наилучший баланс удобства и безопасности. Параллельно не забудьте про заголовки защиты — см. настройку Security Headers для Nginx и Apache.

Ещё один аспект — невозможность «разрешить всё». Многие директивы фиксируются провайдером как php_admin_value и не могут быть изменены из .user.ini или .htaccess: это сделано намеренно, чтобы защитить платформу и ваших соседей.

PATH_INFO, маршрутизация и безопасность

Исторически переменная PATH_INFO в CGI и FastCGI обрабатывалась по‑разному, что приводило к тонким багам при маршрутизации. В современном продакшене для Nginx+FPM рекомендуют держать cgi.fix_pathinfo = 0 и полагаться на корректный try_files или явные правила роутинга, чтобы избежать исполнения «почти подходящих» скриптов.

Локальные настройки: .user.ini, .htaccess и что реально работает

На Apache с mod_php когда‑то можно было менять почти всё через .htaccess с php_value. В мире FPM локальные изменения обычно делаются через .user.ini, а .htaccess влияет только на сам Apache (переписывание URL, кеши, заголовки). LSAPI, будучи тесно связан с Apache‑совместимой конфигурацией, поддерживает знакомую семантику правил, но не отменяет ограничений провайдера на критичные директивы PHP.

Базовые рекомендации:

• Храните проектные директивы в .user.ini и репозитории, чтобы понятна была причина изменения лимитов.
• Для загрузок больших файлов согласовывайте одновременно client_max_body_size на фронте и upload_max_filesize/post_max_size в PHP.
• Если ловите 504 на длинных бэкенд‑операциях, проверьте пары таймаутов: веб‑сервер ↔ пул PHP и сами max_execution_time/request_terminate_timeout.

Диагностика: как понимать, где «узкое место»

Универсальная последовательность для FPM/LSAPI:

• Проверьте логи ошибок PHP и веб‑сервера: сообщения вида «Primary script unknown», «upstream sent too big header», «upstream prematurely closed connection» часто мгновенно указывают направление.
• Посмотрите занятость пула: число активных воркеров, очередь. При постоянной очереди увеличьте pm.max_children или оптимизируйте приложение.
• Оцените время ответа upstream: если веб‑сервер ждёт дольше таймаута, но PHP работает, увеличьте fastcgi_read_timeout или переразбейте долгие операции на фоновые задачи.
• Проверьте опкеш: нет ли исчерпания opcache.memory_consumption, не слишком ли часто идёт валидация таймстемпов.

Типичные ошибки конфигурации и их симптомы

• 502 Bad Gateway сразу после загрузки: нет соединения с пулом или неверный путь к сокету/порту; права на сокет не совпадают с пользователем веб‑сервера.
• 504 Gateway Timeout под нагрузкой: пул забит, очередь растёт; несогласованные таймауты веб‑сервера и пула.
• Случайные 500 на больших ответах: недостаточные буферы FastCGI для заголовков или тела; проверьте fastcgi_buffers и аналоги в Apache.
• Медленный холодный старт после деплоя: opcache очистился и не успел прогреться; планируйте прогрев кэша после развёртывания.

Производительность на практике: что даёт больше всего

• Включённый и достаточно большой opcache.
• Рациональный выбор режима пула: dynamic для переменного трафика, static для предсказуемых высоких нагрузок, ondemand для экономии памяти на редких обращениях.
• Оптимизация I/O: кэширование шаблонов, сессий и объектов; минимизация блокировок; вынесение долгих операций в очередь/воркеры.
• Согласованные лимиты и таймауты на всех слоях.

Короткая памятка выбора

• CGI — только для совместимости, не для продакшена.
• FastCGI как транспорт — ок; как самостоятельный режим встречается всё реже.
• PHP‑FPM — универсальный выбор, предсказуем и хорошо диагностируется.
• LSAPI — отличен на площадках с LiteSpeed/OpenLiteSpeed, особенно для типичных CMS.

Когда пора выходить за рамки виртуального хостинга

Если бизнес‑требования требуют ручного контроля над pm.*, размерами opcache, отдельными пулами на микросервисы и тонкой трассировки, то пределы шаред‑площадки быстро начнут мешать. В такой момент лучше выносить проект на собственную среду с выделенными ресурсами — например, на VDS, чтобы самостоятельно управлять PHP‑FPM/LSAPI и окружением. Это не отменяет базовых правил оптимизации, но делает поведение предсказуемым и измеримым.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Итоги

Эволюция PHP‑режимов — это путь от разовых процессов к стабильным пулам с общим кэшем и чёткими лимитами. Для виртуального хостинга по соотношению скорости, стабильности и управляемости сегодня выигрывают PHP‑FPM и LSAPI. Правильно выставленные таймауты и opcache, разумный выбор режима пула и базовая гигиена приложения дают львиную долю производительности и экономят часы диагностики в выходные.