Сравнение обработчиков PHP: влияние на производительность веб-хостинга

Это сравнение обработчиков PHP показывает, как mod_php, CGI, FastCGI, PHP-FPM и LSAPI Производительность твоего хостинга – от загрузки ЦП до задержек. Я подробно объясню, какой выбор лучше сделать в случае WordPress, WooCommerce и пиковых нагрузок трафика. Время загрузки снижает и одновременно экономит ресурсы.

Центральные пункты

• PHP-FPM масштабируется более эффективно, чем mod_php и FastCGI.
• LSAPI обеспечивает лучшие показатели на LiteSpeed.
• Изоляция на пользователя повышает безопасность.
• OPcache и Redis сокращают задержки.
• P95/P99 показывает реальный опыт пользователей.

Как работают обработчики PHP

PHP-обработчик соединяет веб-сервер с интерпретатором и управляет Процессы, память и ввод-вывод для каждого запроса. CGI запускает новый процесс для каждого запроса и перезагружает конфигурации, что создает накладные расходы и увеличивает Латентность . Современные варианты, такие как FastCGI, PHP-FPM или LSAPI, поддерживают постоянную готовность рабочих процессов, что позволяет сэкономить время запуска, смену контекста и циклы ЦП. OPcache остается в памяти, благодаря чему байт-код не нужно компилировать каждый раз, а динамические страницы отвечают быстрее. В то же время управление процессами определяет, сколько одновременных запросов может выполняться, как устанавливаются приоритеты и как можно смягчить пиковые нагрузки.

Прямое сравнение популярных хендлеров

Выбор обработчика определяет Масштабирование, модель безопасности и потребности в оперативной памяти приложения. mod_php интегрирует PHP в процесс Apache и обеспечивает быстрое время отклика, но страдает слабой Изоляция между учетными записями. CGI четко разделяет пользователей, но требует значительных затрат процессорного времени на каждый запрос. FastCGI снижает накладные расходы, но остается менее эффективным, чем хорошо настроенный PHP-FPM. LSAPI еще больше усиливает этот эффект при использовании LiteSpeed и стабилизирует, в частности, задержки в хвосте при большом количестве одновременных подключений.

обработчик	Производительность	Безопасность	Требование к оперативной памяти	Масштабируемость	Оперативный сценарий
mod_php	Высокий	Низкий	Низкий	Средний	Небольшие сайты, редкие пики
CGI	Низкий	Высокий	Высокий	Низкий	Статический контент, тесты
FastCGI	Средний	Средний	Средний	Средний	временное решение
PHP-FPM	Очень высокий	Высокий	Низкий	Высокий	Виртуальный хостинг, CMS
LSAPI	Самый высокий	Средний	Очень низкий	Очень высокий	Высокая посещаемость, электронная коммерция

PHP-FPM в практическом тестировании: процессы, пулы, настройка

PHP-FPM работает с пулами рабочих процессов, которые извлекают запросы из очереди и тем самым Пики нагрузки элегантно смягчить. Я создаю отдельный пул для каждого веб-сайта, чтобы конфигурация, ограничения и контекст пользователя оставались раздельными, а Безопасность растет. На практике адаптивные настройки, такие как pm = dynamic или ondemand, окупаются, поскольку количество активных процессов адаптируется к спросу. Решающим фактором является правильное определение размера pm.max_children и временных ограничений, чтобы очередь не росла и при этом оставались резервы ОЗУ. Для начала я рекомендую проверить параметры в структурированном виде; подробности о тонкой настройке я объясняю здесь: Управление процессами PHP-FPM.

LSAPI и LiteSpeed: максимальная производительность при высокой одновременности

LSAPI хранит процессы PHP в памяти и сокращает количество переключений контекста, что позволяет динамический контент с помощью HTTP/3 и QUIC еще более плавно. При полной нагрузке задержка P95/P99 остается более стабильной, чем у многих альтернативных решений, что Пользовательский опыт заметно улучшилось. Я регулярно наблюдаю больше запросов в секунду и более короткое TTFB на страницах магазина и контента, особенно когда OPcache и серверный кэш работают вместе. Преимущество проявляется не только в средних значениях, но и в одновременных сессиях, сессиях с промахами кэша и „холодных“ PHP-рабочих процессах. Если вы хотите понять разницу в архитектуре, прочтите обзор LiteSpeed против Nginx и затем принимает решение о стеке.

WordPress и WooCommerce: правильная классификация измеренных значений

В WordPress я достигаю высоких результатов с PHP 8.2 на FPM или LSAPI. запросов в секунду, в то время как WooCommerce обрабатывает несколько меньше запросов в секунду из-за сессий, логики корзины и большего количества обращений к базе данных. Тест становится значимым только в реалистичных условиях. Трафик с смешанными хитами и промахами кэширования. Критический CSS, кэш объектов и постоянные соединения сдвигают границу, за которой возникают узкие места. Особенно полезны короткие TTL для часто изменяемого контента и дифференцированные ключи кэша для языка, статуса пользователя и типа устройства. Таким образом, страница остается быстрой, несмотря на то, что она предоставляет персонализированный контент.

Безопасность и изоляция: пулы, контекст пользователя, ограничения

Я предпочитаю отдельный хостинг для многопользовательских сайтов. бассейны для каждого аккаунта, чтобы права, пути и ограничения оставались четко разделенными друг от друга. mod_php делит общий контекст, что Риск увеличивается, если в проекте есть пробелы. FPM или LSAPI с настройками для каждого пользователя значительно сокращают эту уязвимость, поскольку процессы запускаются под соответствующим пользователем. К этому добавляется возможность устанавливать различные параметры php.ini на уровне проекта, не влияя на другие сайты. Ограничения ресурсов, такие как max_execution_time и memory_limit для каждого пула, предотвращают замедление работы сервера из-за выбросов.

Потребление ресурсов и планирование ОЗУ

Каждый PHP-рабочий процесс занимает, в зависимости от кода, расширений и OPcache-Размер памяти значительно варьируется, поэтому я измеряю фактическое использование, а не делаю предположения. Такие инструменты, как ps, top или systemd-cgtop, показывают, сколько оперативной памяти действительно занимают активные рабочие процессы и когда. своп . Затем я устанавливаю pm.max_children на консервативном уровне, оставляю запас для базы данных, веб-сервера и кэш-сервисов и наблюдаю за задержкой P95 в пиковые моменты. Если остаются резервы, я постепенно увеличиваю количество дочерних процессов и снова проверяю. Таким образом, общая емкость растет контролируемо, без перегрузки сервера.

Методика измерения: от TTFB до P99

Я оцениваю не только средние показатели, но прежде всего P95– и задержки P99, потому что они отражают реальный опыт под нагрузкой. Стек может работать с одинаковой пропускной способностью, но при этом иметь худшие показатели по P99, если Очереди растут. Поэтому я тестирую холодные и теплые кэши, смешиваю запросы на чтение и запись и использую реалистичные значения параллелизма. Без прогрева OPcache я осторожно интерпретирую результаты, поскольку многие системы становятся значительно быстрее после нескольких вызовов прогрева. Только после проведения репрезентативных тестов я принимаю решение о обработчиках, стратегии кэширования и ограничениях процессов.

Руководство по выбору дилера

Для небольших сайтов с небольшим количеством входов достаточно mod_php или экономичного FPM-Настройка, если учитываются аспекты безопасности. Если одновременность растет, я перехожу на PHP-FPM с отдельными пулами для каждого проекта и последовательно активируйте OPcache. Для сильно динамичных магазинов и большого количества сессий я предпочитаю LiteSpeed с LSAPI, чтобы P95 и P99 оставались на низком уровне. Те, кто по ценовым или архитектурным причинам остаются на Apache/Nginx, могут отлично работать с хорошо настроенным FPM. Во всех случаях измерения в реалистичных условиях имеют большее значение, чем тесты на пустой системе.

Настройка практики: кэширование, сессии, временные ограничения

Я ставлю на OPcache с щедрым Память-Распределение, чтобы байт-код редко вытеснялся, и по возможности переносить сессии в Redis, чтобы избежать блокировки файлов. Это сокращает время ожидания при одновременном входе в систему и персонализированных страницах. Для внешних сервисов я определяю четкие таймауты и прерыватели, чтобы сбои не блокировали весь запрос. На уровне приложения я держу TTL кэша достаточно короткими, чтобы обеспечить актуальность, но достаточно длинными для высокого коэффициента попаданий. Те, кто регулярно сталкивается с ограничениями рабочих процессов, найдут здесь начало: Правильное балансирование PHP-рабочих процессов.

Соотношение затрат и выгод и эксплуатация

Я оцениваю Стоимость изменения в пользу измеримой выгоды в виде латентности, пропускной способности и надежности. Переход с FastCGI на PHP-FPM часто дает больше, чем изменение номера побочной версии PHP, потому что Процесс-управление и кэширование работают непрерывно. LSAPI особенно полезен, если LiteSpeed уже используется и ожидается большое количество одновременных посетителей. При переходе на новый стек следует внимательно следить за логами и метриками и подготовить пути для отката. Наиболее надежные результаты дает запланированная A/B-эксплуатация в течение нескольких дней.

Взаимодействие веб-серверов: Apache-MPM, Nginx и Keep-Alive

На практике решающим фактором является не только обработчик PHP, но и режим веб-сервера. mod_php работает с Apache в режиме prefork-MPM, но блокирует использование современных моделей событий. Если вы хотите эффективно использовать HTTP/2, более длительные фазы Keep-Alive и тысячи соединений, выбирайте Apache. мероприятие + PHP-FPM или на Nginx/LiteSpeed в качестве фронтенда. Следствие: количество необходимых PHP-рабочих процессов зависит не от количества TCP-соединений, а от фактически в одно и то же время текущих PHP-запросов. Таким образом, мультиплексирование HTTP/2/3 снижает нагрузку на веб-сервер, но не влияет на недостаточные размеры PHP-пулов.

Nginx обычно перенаправляет запросы в FPM через FastCGI. Я обращаю внимание на короткие read_timeout- и send_timeout-значения на прокси, иначе при зависании восходящих потоков возникают ошибки 502/504, хотя PHP продолжает работать. В средах Apache я ограничиваю Keep-Alive таким образом, чтобы длительные неактивные соединения не занимали пул потоков. LiteSpeed абстрагирует многое из этого, но в полной мере реализует свои преимущества только с LSAPI.

OPcache, JIT и предварительная загрузка: что действительно помогает

OPcache является обязательным. На практике я выбираю размеры opcache.memory_consumption щедрым (например, 192–512 МБ в зависимости от кодовой базы) и увеличьте opcache.max_accelerated_files, чтобы не происходило выселений. Для сборок, которые редко развертываются, я отключаю validate_timestamps или установи более высокое revalidate_freq, чтобы сэкономить системные вызовы. Предварительная загрузка может ускорить работу фреймворков, но особенно эффективен при наличии последовательной структуры автозагрузки. Это JIT PHP редко приносит преимущества при классических веб-нагрузках и может даже потреблять оперативную память; я включаю его только в том случае, если это подтверждается тестами в реальных условиях.

Управление очередью и обратное давление

Большинство узких мест возникает не в ЦП, а в очередь. Если поступает больше запросов, чем могут обработать работники, очередь растет, а задержка P95/P99 резко увеличивается. Я убеждаюсь, что pm.max_children достаточно велик, чтобы поглотить типичные пики, но достаточно мал, чтобы сохранить резерв ОЗУ. pm.max_requests Я устанавливаю умеренное значение (например, 500–2000), чтобы утечки памяти не приводили к появлению долгоживущих процессов. список.задержка должен соответствовать отставанию веб-сервера, иначе ядро будет отбрасывать соединения под нагрузкой. Измерив скорость поступления (запросов в секунду) и среднее время обслуживания, можно с помощью простого расчета пропускной способности оценить, при какой параллельности происходит перелом задержки.

Таймауты, загрузки и долгоиграющие файлы

Длительные загрузки или вызовы API блокируют работу работников. Я устанавливаю четкие ограничения: максимальное_время_выполнения и request_terminate_timeout в FPM предотвращают бесконечное выполнение неисправных запросов. На уровне прокси я синхронизирую proxy_read_timeout/fastcgi_read_timeout с ограничениями FPM, чтобы не произошло преждевременное 504. Большие загрузки я стримую, ограничиваю post_max_size и upload_max_filesize строго и планируйте выделенные конечные точки, чтобы не пострадал остальной трафик. Для длительных заданий, подобных cron, я переношу работу в Кии или задания CLI, вместо того чтобы блокировать фронтенд-рабочих на несколько минут.

Сессии и блокировка в деталях

Сессии PHP по умолчанию блокирующий. Второй запрос от того же пользователя ждет, пока первый не освободит сессию – это фатально для WooCommerce, если параллельно выполняются Ajax-вызовы. Я досрочно завершаю запись в сессию с помощью session_write_close(), как только больше не требуется никаких изменений. С Redis в качестве бэкэнда сеансов снижается задержка ввода-вывода, но правила блокировки остаются важными. За балансировщиками нагрузки я сознательно выбираю между Sticky Sessions (простые, менее масштабируемые) и stateless Patterns с кэшем объектов, чтобы горизонтальное масштабирование работало правильно.

Мониторинг и устранение неисправностей

Без телеметрии настройка — это полет вслепую. Я активирую статус FPM и медленные логи по пулам, чтобы увидеть узкие места и выявить запросы, которые выделяются.

; для каждого пула pm.status_path = /status ping.path = /ping ping.response = pong request_slowlog_timeout = 3s slowlog = /var/log/php-fpm/www-slow.log pm.max_requests = 1000

Если возникает ошибка 502/504, я сначала проверяю: заполнена ли очередь FPM? Имеется ли CPU-Steal или Swap? Соответствует ли таймаут веб-сервера ограничениям FPM? Взгляните на smaps на работника показывает реальную загрузку RSS, в то время как netstat/сс Обнаруживает переполнение бэклога. Для OPcache я отслеживаю частоту обращений и количество повторных проверок, чтобы избежать вытеснения.

Контейнеры, сокеты и ограничения ресурсов

В контейнерах я обычно использую TCP вместо сокетов Unix между веб-сервером и FPM, чтобы избежать ограничений пространства имен и упростить балансировку нагрузки. Важно обеспечить согласованность cgroup-Ограничения: если контейнер имеет только 1–2 ГБ ОЗУ, pm.max_children должен быть соответственно меньше, иначе сработает OOM-killer. Квоты ЦП сильно влияют на время отклика; я планирую запас и проверяю задержку P95 при превышении лимита. Проблемы NUMA и Core Affinity становятся актуальными при очень высокой нагрузке, в то время как LSAPI в настройках LiteSpeed оптимизирует многое из этого внутренне.

Мульти-PHP версии и расширения

Многие хосты используют несколько версий PHP параллельно. Я изолирую пулы по версиям и сохраняю Расширения Компактный. Каждый дополнительный модуль увеличивает объем оперативной памяти на каждого рабочего процесса и может увеличить время запуска. Я последовательно удаляю неиспользуемые расширения; это часто дает больший эффект, чем небольшое увеличение pm.max_children. При обновлении я планирую короткие фазы прогрева для OPcache, чтобы после развертывания не все пользователи одновременно столкнулись с холодным запуском.

Диета RAM и реалистичное планирование емкости

Вместо использования фиксированных значений я определяю среднюю и максимальную потребность в ОЗУ на одного работника с помощью реального трафика. Из этого я делаю следующий вывод: (доступная ОЗУ – система/БД/кэши) / ОЗУ на одного работника = максимальный разумное значение pm.max_children. Кроме того, я оставляю 15–25 % резерва для всплесков, кэша ядра и непредвиденных пиков. Если приложение время от времени раздувает память, я снижаю порог или сокращаю pm.max_requests, чтобы чаще перерабатывать процессы.

Стратегия тестирования: воспроизводимая нагрузка и реальные шаблоны

Я использую тестовые профили, которые смешивают холодные и теплые кэши, комбинируют GET/POST и постепенно увеличивают параллелизм. Важно: только с активным OPcache и реалистичными временами обдумывания я могу увидеть, остается ли система стабильной при использовании. Постепенное наращивание на протяжении нескольких минут предотвращает искусственные пики при запуске. Оценка фокусируется на TTFB и P95/P99, а не только на среднем RTT или чистом req/s.

Типичные ошибки из практики

• Много 504 под пиком: очередь FPM заполнена, бэклог слишком мал, таймауты на прокси более жесткие, чем в FPM.
• Задержки при развертывании: вытеснение OPcache, отсутствие прогрева, слишком маленький opcache.memory_consumption.
• Хорошие средние значения, плохие P99: слишком много долгосрочных процессов (I/O, внешние API), отсутствие прерывания цепи.
• Высокая загрузка ЦП, низкий показатель req/s: блокировка сеансов или некэшированные запросы к базе данных, которые ограничивают последовательность.

Безопасность эксплуатации и откат

Каждое изменение в обработчике или параметрах пула я запускаю с помощью Флаги характеристик или поэтапно. Я слежу за журналами ошибок и медленных запросов, P95 и коэффициентом ошибок и определяю четкий план восстановления на случай, если показатели изменятся. Второй пул с идентичной версией, но другими параметрами позволяет быстро переключаться между A/B без простоев. При полной нагрузке лучше провести кратковременное автоматическое снижение параллелизма (обратного давления), чем запускать новые рабочие процессы без контроля.

Краткое резюме

Для динамичных сайтов с большим количеством одновременных пользователей я предпочитаю LSAPI на LiteSpeed, в то время как PHP-FPM на Apache или Nginx дает лучший Универсальный игрок mod_php остается специальным случаем для очень простых проектов без строгой изоляции. Решающее значение имеют реалистичные тесты с теплым OPcache, разумными ограничениями пула и чистым кэшированием. Тот, кто надежно снижает задержки, измеряет P95/P99 и в первую очередь реагирует на проблемы Tail, а не на средние значения. Таким образом, приложение достигает заметно более быстрых ответов и большего запаса для пикового трафика.