PHP-FPM
PHP-FPM (рус. менеджер процессов FastCGI для PHP, аббревиатура от PHP FastCGI Process Manager) — официальная реализация протокола FastCGI для PHP, предназначенная для эффективной и безопасной обработки PHP-скриптов на высоконагруженных сайтах. Изначально PHP-FPM существовал в виде стороннего патча и был включён в ядро языка начиная с версии PHP 5.3.3[3][4]. Компонент работает как отдельная служба, поддерживающая пул готовых процессов PHP, что устраняет необходимость порождать новый интерпретатор для каждого запроса и тем самым снижает задержки и нагрузку на ресурсы сервера[5][6].
Общие сведения
| PHP-FPM | |
|---|---|
| англ. PHP FastCGI Process Manager | |
| Область использования | PHP, веб-серверы, Веб-программирование |
| Дата появления | 2004[1] |
| Место появления | Badoo[2] |
| Автор понятия | Андрей Нигматулин[1] |
Определение
PHP-FPM — это:
- полноценный менеджер FastCGI-процессов, встроенный в PHP начиная с версии 5.3.3[5];
- служба, работающая отдельно от веб-сервера (Nginx, Apache, LiteSpeed), принимающая от него FastCGI-запросы через Unix- или TCP-сокеты;
- механизм, который:
- инициализирует «мастер»-процесс;
- формирует один или несколько пулов дочерних (worker) процессов;
- повторно использует уже запущенные процессы для обработки новых запросов;
- изолирует пулы по UID/GID, chroot и набору php.ini-настроек[7].
История
PHP-FPM был разработан в 2004 году программистом Андреем Нигматулиным как сторонний патч для PHP. Решение создавалось для социальной сети Badoo с целью оптимизации работы сайтов с высокой нагрузкой. В отличие от стандартной реализации FastCGI, PHP-FPM решал ряд критических для высоконагруженных систем проблем: позволял перезапускать пул обработчиков без потери запросов, запускать разные пулы от имени разных пользователей и обеспечивал аварийный перезапуск дочерних процессов в случае сбоев[8].
Благодаря своей эффективности патч привлёк внимание PHP-сообщества. В середине 2009 года он был переработан из формата патча в более модульную структуру. 22 июля 2010 года PHP-FPM был официально включён в ядро PHP, начиная с версии 5.3.3, что сделало его стандартной частью языка и избавило от необходимости отдельной установки[9]. 29 ноября 2011 года, с выходом версии PHP 5.4.0RC2, компонент перестал считаться «экспериментальным».
Архитектура и компоненты
Архитектура PHP-FPM включает следующие ключевые элементы[10]:
- Master-процесс — родительский демон, читающий конфигурацию, создающий пулы, обрабатывающий сигналы и контролирующий жизненный цикл дочерних процессов;
- Пул процессов (pool) — логическая группа worker-процессов с собственным сокетом, uid/gid и набором директив php.ini; в одном экземпляре FPM может быть произвольное число пулов;
- Worker-процессы — дочерние процессы PHP-интерпретатора, непосредственно выполняющие код скрипта;
- Слушатель сокета — Unix- или TCP-сокет, через который веб-сервер передаёт запросы пулу;
- Общая (shm) статистика — сегмент памяти, в котором master хранит счётчики запросов, ошибок и время жизни процессов.
Master-процесс и worker-процессы
Master загружает конфигурацию, открывает сокеты и далее управляет воркерами: порождает, завершает, перезапускает их по сигналам и по внутренним алгоритмам планировщика. Состояния воркера:
- idle — ожидает запрос;
- running — обрабатывает скрипт;
- terminating — завершается по плану или по ошибке.
Worker может быть перезапущен после заданного числа запросов (``pm.max_requests``) для предотвращения утечек памяти[11].
Конфигурация
Глобальный файл ``php-fpm.conf`` задаёт PID-файл, уровень логирования, директиву ``include`` и путь к конфигурациям пулов.
Каждый пул описывается отдельным ``*.conf``-файлом (по умолчанию — ``www.conf``) и содержит[12]:
- базовые параметры
``user``, ``group``, ``listen`` (Unix или TCP), ``listen.owner/group/mode``
- менеджер процессов
``pm`` (static | dynamic | ondemand), ``pm.max_children``, ``pm.start_servers``, ``pm.min_spare_servers``, ``pm.max_spare_servers``
- ограничения и тайм-ауты
``request_terminate_timeout``, ``pm.max_requests``
- переопределение php.ini
``php_value[]``, ``php_admin_value[]``
Логирование и мониторинг
- ``error_log`` — основной журнал ошибок PHP-FPM; значение ``syslog`` перенаправляет записи в системный журнал.
- ``slowlog`` + ``request_slowlog_timeout`` — трассировка медленных скриптов.
- ``catch_workers_output`` — перенаправление STDOUT/STDERR воркеров в ``error_log``.
- ``pm.status_path`` и ``ping.path`` — встроенные URI для экспорта метрик и проверки «живости» сервиса[11].
В сентябре 2024 года была устранена уязвимость подделки логов (CVE-2024-9026), затрагивающая error_log. Она позволяла злоумышленнику добавлять или удалять символы в записях, что затрудняло расследование инцидентов[13]. Исправление было выпущено 26 сентября 2024 года в версиях PHP 8.1.30, 8.2.24 и 8.3.12[14].
Сокеты и интерфейсы
PHP-FPM поддерживает два типа слушателей[15]:
- Unix Domain Socket (`/run/php/php8.2-fpm.sock`) — быстрее за счёт отсутствия сетевого стека; права доступа регулируются ``listen.owner/group/mode``;
- TCP-сокет (`127.0.0.1:9000`) — удобен для разнесённых или контейнерных инсталляций; доступ ограничивается ``listen.allowed_clients``.
Очередь входящих соединений настраивается директивой ``listen.backlog``.
Этапы работы
1. Веб-сервер получает HTTP-запрос. 2. Модуль FastCGI (``fastcgi_pass`` в Nginx или ``proxy_fcgi`` в Apache) пересылает запрос через сокет в нужный пул. 3. Master выбирает свободного worker-процесса. 4. Worker исполняет PHP-код, взаимодействует с БД, формирует ответ. 5. Результат возвращается веб-серверу и далее клиенту[16].
Планирование пула процессов
Алгоритм определяется значением ``pm``[17]:
| Режим | Логика масштабирования | Ключевые директивы |
|---|---|---|
| static | Фиксированное число процессов | ``pm.max_children`` |
| dynamic | Автоматическое увеличение/уменьшение в заданных границах | ``pm.max_children``, ``pm.start_servers``, ``pm.min_spare_servers``, ``pm.max_spare_servers`` |
| ondemand | Процесс создаётся при первом запросе и уничтожается после простоя (``pm.process_idle_timeout``) | ``pm.max_children`` |
Загрузка и парсинг конфигурации
При старте FPM:
- читается ``php-fpm.conf``;
- обрабатываются директивы ``include`` и рекурсивно подключаются все файлы, обычно из ``pool.d/*.conf``;
- файлы считываются в алфавитном порядке, а при совпадении директив применяется правило «последнее значение побеждает».
Валидация и проверка параметров
- ``php-fpm -t`` — сухой прогон для проверки синтаксиса; в случае успеха выводится сообщение «configuration file … test is successful»[18].
- При запуске master дополнительно валидирует права на сокеты, корректность uid/gid и согласованность параметров ``pm``. Ошибки фиксируются в ``error_log``.
Развёртывание и масштабирование
- Вертикальное масштабирование — подбор оптимальных значений ``pm.max_children`` и ``pm.max_requests`` исходя из доступной RAM и среднего потребления одного процесса (~128 МБ).
- Горизонтальное масштабирование — несколько экземпляров FPM за фронтовым балансировщиком (Nginx, HAProxy, AWS ELB).
- В контейнерных средах PHP-FPM разворачивают в собственном образе и масштабируют Deployment-ами Kubernetes или сервисами Docker Compose[19][20].
Мониторинг и автоперезапуск
За автоматический перезапуск отвечают три директивы[21]:
- ``emergencyrestartthreshold`` — число аварийных выходов воркеров; значение 0 (по умолчанию) выключает механизм[22].
- ``emergencyrestartinterval`` — интервал, за который считается порог (например, ``1m``).
- ``process_control_timeout`` — время ожидания корректного завершения воркера перед его принудительным убийством.
Безопасность
В сентябре 2024 года было объявлено о нескольких уязвимостях, затрагивающих PHP, две из которых имели прямое отношение к FPM:
- CVE-2024-9026 — уязвимость подделки логов (log manipulation). Она позволяла злоумышленнику манипулировать записями в файле
error_log, добавляя или удаляя символы, что существенно затрудняло расследование инцидентов. Проблема была устранена 26 сентября 2024 года в версиях PHP 8.1.30, 8.2.24 и 8.3.12. - CVE-2024-8927 — уязвимость, позволяющая обойти директиву
cgi.force_redirect. В определённых конфигурациях это могло привести к несанкционированному доступу к файлам.
Альтернативы и экосистема
Несмотря на то, что PHP-FPM остаётся промышленным стандартом для развёртывания PHP-приложений[23], в 2024 году активное развитие получили альтернативные подходы и инструменты.
Одной из наиболее заметных альтернатив стал FrankenPHP — сервер приложений, написанный на языке Go. Он позиционируется как более производительное решение, способное обрабатывать запросы до трёх раз быстрее, чем традиционная связка с PHP-FPM[24].
Кроме того, на конференции HighLoad++ 2024 были представлены планы по интеграции запуска PHP-процессов непосредственно в веб-сервер Angie, являющийся форком Nginx. Такой подход может устранить необходимость в PHP-FPM как в отдельном компоненте, снижая накладные расходы на взаимодействие и упрощая конфигурацию[25].
В 2024 году фонд The PHP Foundation анонсировал новый инструмент Web Services Tool (WST) — консольную утилиту, специально разработанную для тестирования PHP-FPM[26]. Также в сообществе обсуждалось RFC о возможности совместного использования HTTP-соединений между запросами в FPM для повышения производительности[27].
Преимущества
- повторное использование процессов снижает накладные расходы и ускоряет отклик[16];
- гибкая изоляция приложений по пулам и индивидуальным php.ini;
- поддержка медленного лога и страницы статуса для диагностики;
- «мягкая» перезагрузка без прерывания активных соединений;
- эффективная работа с OPcache повышает производительность[7].
Недостатки
- требует более тщательной настройки, чем модуль ``mod_php``;
- при ошибочных значениях ``pm.max_children`` возможны 502/503 из-за исчерпания воркеров;
- устаревшие приложения на Apache могут потерять часть конфигурации .htaccess и потребовать миграции[28];
- уступает в производительности более современным серверам приложений, таким как FrankenPHP, и имеет накладные расходы на взаимодействие с веб-сервером, которые устраняются в альтернативных архитектурах.
Сферы применения
- высоконагруженные интернет-порталы и SaaS-платформы;
- многосайтовый виртуальный хостинг с изоляцией клиентов;
- e-commerce (Magento, WooCommerce);
- API-бэкенды на Laravel/Symfony;
- контейнерные микросервисы, обслуживающие PHP-фоновые задачи[6].
Панели управления и графические интерфейсы
cPanel/WHM, Plesk, ISPmanager, DirectAdmin и Virtualmin позволяют включать FPM для доменов, редактировать значения ``pm.max_children`` и перезапускать службу из GUI[29].
Утилиты командной строки
- ``php-fpm -t`` — тест конфигурации;
- ``php-fpm -v`` — версия;
- ``systemctl restart php-fpm`` / ``service php-fpm restart`` — перезапуск службы;
- сигналы ``USR2`` (graceful reload) и ``QUIT`` (graceful quit) для PID master-процесса[18].
Интеграция с веб-серверами
- Nginx — директива ``fastcgi_pass`` указывает путь к сокету пула; полный набор FastCGI-параметров подключается файлом ``fastcgi_params``.
- Apache — модуль ``mod_proxy_fcgi`` (``SetHandler «proxy: unix:/run/php/php-fpm.sock|fcgi://localhost/»``) направляет PHP-запросы на FPM; рекомендуется MPM Event или Worker.
- Angie — в форке Nginx были анонсированы планы по прямой интеграции запуска PHP-процессов в веб-сервер. Такой подход может в будущем устранить необходимость в PHP-FPM как в отдельном компоненте, снижая накладные расходы на взаимодействие.
Интеграция с контейнерами и оркестраторами
- Docker — официальные образы ``php:8.x-fpm(-alpine)``; код приложения монтируется в ``/var/www/html``; OPcache и значения ``pm.*`` настраиваются через переменные окружения или том с конфигом.
- Docker Compose — отдельные сервисы ``nginx`` и ``php-fpm`` в общей сети; FPM экспортирует порт 9000 только внутрь сети.
- Kubernetes — раздельные Deployment’ы для Nginx и PHP-FPM, headless-Service для FastCGI-трафика, HPA по метрике свободных воркеров.
- С выходом PHP 8.5 ожидается улучшение для контейнерных сред: опция ``opcache.file_cache_read_only=1`` позволит оптимизировать работу OPcache в файловых системах, доступных только для чтения, что характерно для неизменяемых (immutable) образов[30].