Что такое PHP-FPM и чем он отличается от классического подхода в PHP

Раньше PHP на сервере чаще всего работал по классической схеме: веб-сервер сам запускал PHP-код или был напрямую связан с PHP-модулем. Сегодня для большинства современных сайтов используется другой подход — PHP-FPM.

На первый взгляд разница может казаться технической мелочью, но на практике от способа запуска PHP зависят скорость сайта, стабильность, потребление памяти и удобство администрирования.

Классический подход: PHP внутри веб-сервера

Один из старых и долгое время популярных вариантов работы PHP — использование mod_php вместе с Apache.

В такой схеме PHP фактически подключался к Apache как модуль. Когда пользователь открывал PHP-страницу, Apache сам обрабатывал запрос и выполнял PHP-код внутри своих процессов.

Пользователь
    ↓
Apache
    ↓
mod_php
    ↓
PHP-скрипт
    ↓
HTML-страница

Такой подход был простым и удобным: установил Apache, подключил PHP-модуль — и сайт работает. Именно поэтому он долго использовался на обычных хостингах, старых VPS и небольших проектах.

В чем минусы старого подхода

Главная проблема классической схемы в том, что каждый процесс Apache становился достаточно «тяжелым», потому что внутри него был подключен PHP.

Даже если Apache отдавал обычную картинку, CSS-файл или HTML-страницу, процесс всё равно мог нести с собой лишнюю нагрузку PHP-модуля. На небольшом сайте это почти незаметно, но при росте посещаемости сервер начинал расходовать больше памяти.

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

Что изменил PHP-FPM

PHP-FPM — это отдельный менеджер процессов PHP. В этой схеме веб-сервер и PHP работают раздельно.

Например, Nginx или Apache принимает запрос от пользователя. Если нужно выполнить PHP-скрипт, веб-сервер передает его в PHP-FPM. PHP-FPM выбирает свободный PHP-процесс, выполняет код и возвращает готовый результат обратно веб-серверу.

Пользователь
    ↓
Nginx / Apache
    ↓
PHP-FPM
    ↓
PHP-процессы
    ↓
HTML-страница

То есть PHP больше не встроен напрямую в веб-сервер. Он работает как отдельный сервис.

Главное отличие PHP-FPM от mod_php

При использовании mod_php PHP живет внутри Apache. При использовании PHP-FPM PHP работает отдельно, а веб-сервер только передает ему запросы на выполнение скриптов.

Это разделение дает больше гибкости: веб-сервер занимается HTTP-запросами, статикой, редиректами и проксированием, а PHP-FPM занимается только выполнением PHP-кода.

Сравнение PHP-FPM и классического подхода

Что такое пулы PHP-FPM

Одно из важных преимуществ PHP-FPM — возможность создавать отдельные пулы процессов.

Пул — это группа PHP-процессов с отдельными настройками. Например, для разных сайтов на одном сервере можно создать разные пулы:

/etc/php/8.2/fpm/pool.d/site1.conf
/etc/php/8.2/fpm/pool.d/site2.conf

Для каждого сайта можно настроить:

• отдельного пользователя Linux;
• лимит памяти;
• количество PHP-процессов;
• путь к логам;
• параметры производительности;
• отдельные настройки PHP.

Это удобно, если на сервере размещено несколько проектов. Один сайт не должен забирать все ресурсы сервера и мешать работе остальных.

Почему PHP-FPM лучше подходит для современных сайтов

Современный сайт редко состоит только из PHP-страниц. Обычно на сервере есть изображения, CSS, JavaScript, шрифты, API-запросы, кеш, загрузки файлов и административная часть.

В такой архитектуре логичнее разделить обязанности:

• Nginx быстро отдает статику и принимает запросы;
• PHP-FPM выполняет PHP-код;
• MySQL или MariaDB работает с базой данных;
• Redis или Memcached может использоваться для кеша.

Такая схема проще масштабируется и лучше подходит для высоконагруженных проектов.

PHP-FPM и Битрикс

Для сайтов на 1С-Битрикс PHP-FPM особенно полезен, потому что Битрикс активно использует PHP, работает с базой данных, кешем, агентами, административной частью и обработкой пользовательских запросов.

На практике PHP-FPM позволяет:

• гибко настроить количество PHP-процессов;
• ограничить потребление памяти сайтом;
• разнести разные сайты по отдельным пулам;
• использовать Nginx как быстрый фронтенд;
• упростить диагностику проблем с производительностью.

Например, если в логах появляется ошибка:

server reached pm.max_children setting

это означает, что сайту не хватает доступных PHP-процессов. В такой ситуации можно анализировать нагрузку, среднее потребление памяти одним процессом и корректировать настройки PHP-FPM.

Основные настройки PHP-FPM

Один из ключевых файлов настройки пула PHP-FPM может выглядеть так:

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

Здесь важно понимать несколько параметров.

pm.max_children — максимальное количество PHP-процессов, которые могут одновременно обрабатывать запросы.

pm.start_servers — сколько процессов будет запущено при старте PHP-FPM.

pm.min_spare_servers и pm.max_spare_servers — минимальное и максимальное количество свободных процессов, которые PHP-FPM старается держать в ожидании новых запросов.

Когда старый подход еще может встречаться

Классический подход с mod_php все еще можно встретить на старых серверах, небольших проектах или устаревших конфигурациях хостинга.

Если сайт небольшой и не испытывает нагрузки, такая схема может работать годами. Но при росте посещаемости, появлении нескольких сайтов на одном сервере или необходимости тонкой настройки производительности PHP-FPM обычно оказывается более правильным решением.

Нужно ли обязательно переходить на PHP-FPM

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

Но если вы настраиваете новый сервер, переносите сайт на VPS, оптимизируете Битрикс, WordPress, Laravel или другой PHP-проект, лучше сразу использовать современную схему:

Nginx → PHP-FPM → PHP → MySQL

Это более гибкий, производительный и удобный вариант для дальнейшего развития сайта.

Вывод

PHP-FPM отличается от классического подхода тем, что PHP работает не внутри веб-сервера, а как отдельный управляемый сервис.

Благодаря этому сервер становится гибче: можно отдельно настраивать PHP-процессы, ограничивать ресурсы, создавать пулы для разных сайтов и эффективнее использовать связку Nginx + PHP.

Старый подход с mod_php был простым и удобным для своего времени, но для современных PHP-проектов PHP-FPM стал более правильным стандартом. Особенно это актуально для сайтов на 1С-Битрикс, где производительность и стабильность серверной части напрямую влияют на работу всего проекта.