Перейти к содержимому 
Сравнение обработчиков PHP наглядно показывает, как CGI, PHP-FPM и LSAPI управляют выполнением PHP-скриптов и тем самым характеризуют задержки, изоляцию и требования к оперативной памяти в хостинге. Я объясняю различия с практической точки зрения, классифицирую их в зависимости от рабочей нагрузки и даю рекомендации по выбору и настройке в повседневной работе.
Центральные пункты
- ПроизводительностьLSAPI лидирует по задержкам в хвосте, PHP-FPM обеспечивает очень постоянное время отклика.
- БезопасностьCGI строго разделяет, PHP-FPM изолирует с помощью пулов, LSAPI инкапсулирует для каждого пользователя.
- РесурсыLSAPI экономит оперативную память, PHP-FPM остается эффективным, CGI создает накладные расходы.
- СовместимостьPHP-FPM подходит для Apache/Nginx, LSAPI работает с LiteSpeed.
- ПрактикаДля CMS и магазинов я в основном использую PHP-FPM; для большого количества трафика часто используется LSAPI.
Основы работы с обработчиками PHP
Обработчик PHP соединяет веб-сервер с Интерпретатор PHP. CGI запускает новый процесс для каждого запроса и таким образом достигает очень чистого разделения между учетными записями. Такое разделение требует затрат времени, поскольку при каждом запросе происходит перезагрузка расширений и конфигурации. PHP-FPM сохраняет постоянство рабочих процессов и распределяет запросы по пулам, что снижает затраты на запуск и сохраняет низкую задержку. LSAPI глубоко интегрирован с LiteSpeed и использует очень легкие, долгоживущие процессы для Высокая эффективность.
Mod_php интегрирует PHP непосредственно в веб-сервер, но изоляция слабая. Я предпочитаю современные обработчики, потому что они минимизируют источники ошибок и делают платформу более стабильной под нагрузкой. Если вы размещаете много пользователей на одной системе, вам явно выгоднее использовать отдельные Пользовательские контексты. Именно здесь FPM-пулы и LSAPI играют свою роль. CGI остается безопасным, но медленным вариантом для очень маленьких сайтов и специальных тестовых сценариев.
Сравнительная таблица: сильные стороны и сценарии применения
В следующей таблице приведены основные характеристики и их соответствие типичным рабочим нагрузкам. Я использую ее в качестве быстрого помощника в принятии решений для хостинг php-установки с CMS, магазинами или API. Обратите внимание, что фактическая производительность также зависит от кэширования, хранилища и сетевого профиля. Тем не менее, этот обзор обеспечивает надежную отправную точку для первоначального выбора. Затем я настраиваю конфигурацию в зависимости от конкретных профилей нагрузки и Измеренные значения.
| обработчик | Производительность | Безопасность | Потребление оперативной памяти | Масштабируемость | Подходит для |
|---|---|---|---|---|---|
| CGI | Низкий | Очень высокий | Высокий | Низкий | Тесты, статичные или редко посещаемые страницы |
| PHP-FPM | Очень высокий | Высокий | Низкий | Высокий | Общий хостинг, CMS, API |
| LSAPI | Самый высокий | От среднего до высокого (на одного пользователя) | Очень низкий | Очень высокий | Высокий трафик, электронная коммерция, параллелизм |
CGI оценивает Разделение, но страдает от затрат на запуск процесса. PHP-FPM предлагает наилучшее соотношение задержек, пропускной способности и изоляции в системах с Apache или Nginx. LSAPI обеспечивает очень низкие хвостовые задержки при высокой конкуренции на стеках LiteSpeed. Если вы не используете сервер LiteSpeed, FPM предлагает самую широкую поддержку. Для очень маленьких сайтов я придерживаюсь простых настроек; для растущих проектов я перехожу на FPM или LSAPI.
Производительность под нагрузкой: задержка и пропускная способность
В условиях растущей конкуренции задержки P95/P99 и Стабильность пропускной способности. LSAPI держит самую высокую нагрузку с удивительно стабильным временем отклика. PHP-FPM следует вплотную за ним и очень хорошо реагирует на настройку пула, например, с помощью динамических номеров процессов. CGI заметно теряет скорость, как только поступает много коротких запросов. Для более детальных измерений, пожалуйста, обратитесь к моим Сравнение производительности, который охватывает типичные рабочие нагрузки CMS и магазинов.
Я постоянно комбинирую FPM или LSAPI с OPcache, чтобы байткод не генерировался постоянно заново. Кроме того, кэши обратного прокси уменьшают количество обращений к PHP для повторяющегося контента. Очередь заданий стоит использовать для вычислительных задач, чтобы запросы фронтенда оставались быстрыми. Если вы хотите перехватывать спорадические пики, используйте кратковременное серийное масштабирование с помощью дополнительных рабочих FPM. При этом задержки в хвосте остаются в пределах нормы, а Время реагирования соответствует.
Безопасность и изоляция в виртуальном хостинге
Что важно в многопользовательских средах Изоляция по крайней мере, не меньше, чем скорость. CGI достигает очень чистого разделения через процессы на каждый запрос, но с большими накладными расходами. PHP-FPM изолирует процессы по пулам и допускает жесткие ограничения на память, время выполнения и количество процессов. LSAPI также распределяет процессы по учетным записям, но детально привязан к стеку LiteSpeed. Если вы хотите распределить риски по категориям, лучше всего прочитать мою статью о Объединение рисков с FPM и устанавливает четкие границы.
Я создал отдельный счет для каждого аккаунта. бассейн с собственным UID/GID и ограниченными правами. Это ограничивает радиус возможных атак и не позволяет ошибочным скриптам видеть внешние данные. Сюда входят ограничения на память, максимальное количество запросов на одного рабочего и таймауты. Регулярные обновления и безопасные права доступа к файлам завершают концепцию. Я свожу к минимуму сценарии администрирования, которые находятся в открытом доступе в сети, или защищаю их с помощью Авторизация.
Потребление ресурсов и управление оперативной памятью
Оперативная память часто определяет Стоимость и плотность размещения на сервере. LSAPI здесь выигрывает благодаря очень маленькой площади на процесс и экономичным контекстным переключениям. PHP-FPM также остается эффективным, если я создаю пулы динамически и правильно определяю их размер. CGI тратит память из-за частой перезагрузки расширений и поэтому вряд ли подходит для динамичных проектов. Если вы размещаете много аккаунтов, FPM или LSAPI дают значительно больше резервов на узел и сохраняют Общие затраты планируемый.
Я регулярно измеряю пиковую оперативную память и наблюдаю за ее распределением в течение дня. Пики указывают на слишком низкое количество рабочих или неблагоприятные стратегии кэширования. Я уменьшаю потребность в них с помощью более точного определения размера пула и целенаправленной настройки OPcache. Это снижает риски подкачки и предотвращает непредсказуемые выбросы задержки. На переполненных хостах я перемещаю отдельных работников Сайты на своих узлах, прежде чем пострадает общая производительность.
Совместимость с Apache, Nginx и LiteSpeed
Выбор веб-сервера определяет решение на обработчик. PHP-FPM отлично работает за Nginx и может быть чисто подключен к Apache через прокси. В средах Apache я рекомендую использовать mpm_event, настройку keep-alive и стабильную конфигурацию прокси. LSAPI полностью раскрывает свой потенциал с LiteSpeed и эффективно читает файлы .htaccess. Те, кто уже использует LiteSpeed, часто получают последний бит производительности с LSAPI. Производительность выходить.
Для статического контента я использую Nginx или LiteSpeed непосредственно из кэша веб-сервера. PHP обрабатывает только то, что должно оставаться динамичным. Такое разделение снижает нагрузку на обработчик и экономит процессорное время. Побочный эффект - повышение согласованности TTFB при повторяющихся запросах страниц. Благодаря этому фронтенды остаются отзывчивыми, даже когда бэкэнды находятся под давлением.
Лучшие практики для пулов PHP FPM
Я начинаю с консерватора Расположение бассейна для каждого сайта и измеряю реальные пики. Затем я настраиваю pm, pm.max_children, pm.start_servers и pm.max_requests. Слишком маленькие пулы заставляют запросы ждать, слишком большие пулы съедают оперативную память и вызывают переключение контекста. Для WordPress, WooCommerce или TYPO3 я обычно выбираю динамический или по требованию и жестко регулирую ограничения. Подробности о pm.max_children можно найти в моем руководстве pm.max_children резюмировал он.
Я устанавливаю такие ограничения, как memory_limit и max_execution_time для каждого пула. Это не позволяет отдельным скриптам блокировать ресурсы или выходить из-под контроля. request_terminate_timeout защищает от зависания процессов, которые в противном случае будут накапливаться. max_input_vars и upload_max_filesize разумно защищены, в зависимости от проекта. Это позволяет сохранить пулы управляемый и хост стабилен.
Кэширование и OPcache на практике
Для меня OPcache является частью каждого Установка PHP. Я активирую его, проверяю размер и отслеживаю частоту обращений. Для многих развертываний я устанавливаю file_cache_only и настраиваю revalidate_freq, чтобы развертывания происходили быстро. Я также использую кэши обратного прокси и плагины кэширования страниц в CMS, чтобы снизить частоту обращений к PHP. Чем меньше запросов попадает в PHP, тем лучше он масштабируется. все.
Те, кто интенсивно использует серверные сессии, часто выигрывают от Redis. Я регулирую TTL и строго управляю лимитами памяти. Для полностраничного кэша я учитываю ключи кэша и стратегии аннулирования, чтобы магазины корректно доставляли информацию после изменения цен или акций. Четкий план кэширования экономит процессор, оперативную память и время. Взаимодействие OPcache, прокси-кэша и Кэш приложений в конечном итоге определяет воспринимаемую скорость.
Матрица принятия решений: Какой обработчик подходит для того или иного проекта?
Небольшие сайты с малым трафиком безопасно работают с PHP-FPM и консервативные ограничения. Чистые тестовые среды или особые требования к соответствию могут сделать CGI полезным, несмотря на потерю скорости. Магазины с высоким трафиком и высококонкурентными API часто выигрывают от LSAPI на LiteSpeed. Если вам нужна максимальная совместимость и гибкость, положитесь на FPM. Для хостинга php с WordPress или WooCommerce я предпочитаю FPM как универсальное решение. Универсальный игрок До этого.
Я никогда не принимаю решение, основываясь только на контрольных показателях. Вместо этого я измеряю реальное сочетание статических посещений, динамических страниц и вызовов API. Среднее время выполнения сценария и доля обращений к кэшу также влияют на выбор. Я также учитываю привычки администратора, например, частое развертывание или процессы сборки. Лучшим решением остается то, которое работает в реальных условиях Условия стабильный и быстрый.
Затраты, лицензия и эксплуатация - что окупается?
С точки зрения чистой стоимости FPM привлекателен, поскольку не требует дополнительных лицензий. LSAPI может снизить операционные расходы на один сайт за счет большей плотности и меньших задержек, но требует лицензий LiteSpeed в евро. Для многих платящих клиентов это часто окупается, но не для хобби-проектов. CGI вызывает косвенные расходы за счет неэффективного использования ресурсов и более длительного времени отклика. Поэтому я рассчитываю общую стоимость работы и экономлю там, где это имеет смысл. качество не подвергается опасности.
Умение планировать по-прежнему важно. Хост, который слишком сильно перегружен, экономит деньги в краткосрочной перспективе, но расплачивается за это простоем и недовольством пользователей. Современные инструменты наблюдения помогают распознать узкие места на ранней стадии. Те, кто регулярно увеличивает пропускную способность, поддерживают стабильность задержек и снижают нагрузку на службу поддержки. В конечном итоге решение, которое экономит ресурсы и минимизирует Время работы высокий.
Несколько версий PHP, развертывание и отсутствие простоев
В повседневной жизни я часто оперирую несколькими Версии PHP параллельно. В FPM это достигается с помощью отдельных пулов и отдельных сокетов для каждой версии. Это позволяет мне переносить сайты шаг за шагом, не нарушая работу всей системы. Я планирую скользящие обновления: сначала staging, затем небольшая производственная группа, затем все остальные. Благодатная перезагрузка (FPM: перезагрузка вместо перезапуска) избегать жестких разрывов и держать соединения открытыми. В LSAPI я использую аналогичные механизмы в стеке LiteSpeed для предварительного разогрева рабочих и минимизации эффекта холодного старта.
Для развертывания с нулевым временем простоя я обращаю внимание на стратегии атомарного выпуска с симлинками и Проверка OPcache. После переключения я выборочно очищаю кэш, не удаляя все подряд. Это позволяет поддерживать стабильные хвостовые задержки, а новые развертывания быстро переходят в теплое состояние. Важно: разрешения и владельцы файлов должны быть правильными, иначе FPM или LSAPI workers будут блокировать новые релизы.
Сокеты против TCP: архитектурные решения с последствиями
Обработчик подключается либо через Сокет Unix или через TCP. Сокеты экономят накладные расходы и обычно обеспечивают минимально лучшие задержки на хосте. TCP имеет смысл использовать, если веб-сервер и обработчик работают отдельно или если я хочу распределить пулы по нескольким узлам. Масштаб хотелось бы. Для TCP я четко определяю таймауты, keep-alive и backlog, чтобы во время пиков нагрузки не возникало 502/504 ошибок. В настройках Apache я обращаю внимание на количество активных рабочих прокси, в Nginx - на лимиты открытых соединений. В случае с LSAPI LiteSpeed многое делает сам, но я все равно регулярно проверяю бэклог и очереди под нагрузкой.
Я отслеживаю длину очереди в статусе FPM, загрузку рабочих и насыщенность процессора. Высокая очередь при низком уровне использования часто указывает на узкие места во фронтенде (например, слишком мало рабочих Nginx) или Тормоза ввода/вывода там. Только когда я знаю узкое место, я увеличиваю количество дочерних процессов или настраиваю параметры сети.
Мониторинг, метрики и поиск ошибок
Для наблюдения я полагаюсь на Комплексный мониторингЖурналы веб-сервера, состояние FPM, системные метрики (CPU, RAM, I/O), журналы приложений и синтетические проверки. Особую ценность представляет FPMSlowlog, чтобы выявить отклонения. Я соотношу задержки P95/P99 со скачками CPU, частотой попадания в OPcache, количеством запущенных процессов и задержками баз данных. Если задержка P99 увеличивается, я сначала проверяю очереди и таймауты между прокси и обработчиком.
В случае инцидента я работаю изнутри: 1) коды и время ошибок HTTP, 2) ошибки прокси/веб-сервера, 3) очереди обработчиков и состояния рабочих, 4) журналы приложений, 5) системы бэкенда (БД, кэш, файловая система). Частыми причинами 502/504 являются слишком строгие таймауты, блокировка восходящих потоков или измученный Вместимость бассейна. Простые меры борьбы: реалистичные тайм-ауты, четкие ограничения и предупреждения о том, что до изнеможения.
Файловые системы, детали realpath и OPcache
Доступ к файлам оказывает большее влияние на задержку, чем многие думают. Я обращаю внимание на быстрые Пути хранения для кода и шаблонов. В сетевых файловых системах (например, NFS) параметры realpath и OPcache имеют решающее значение. Достаточно большой размер realpath_cache_size и подходящий ttl предотвращают постоянные разрешения путей. В OPcache я измеряю потребление_памяти, интернированный_буфер_строк и количество Хеш-таблицы Я устанавливаю параметры validate_timestamps и revalidate_freq в соответствии с рабочим процессом развертывания, чтобы изменения вступали в силу быстро, но не вызывали ежесекундных проверок.
Для больших кодовых баз стоит Предварительная загрузка для центральных классов и функций. Это экономит процессорное время FPM или LSAPI-работников на горячем пути. Я тестирую JIT только там, где есть реальные узкие места для процессора (много числовой логики). JIT редко дает преимущества для классических CMS; чистая конфигурация OPcache и быстрый путь ввода-вывода важнее.
Подключение к базе данных и кэшу: избегайте задержек
Многие проблемы с производительностью возникают не из-за обработчика, а из-за Базы данных и кэши. Я слежу за временем выполнения запросов, пулами соединений и блокировками. Постоянные соединения могут помочь, но они связать оперативной памяти в рабочих. Поэтому я определяю размер pm.max_children в соответствии с ограничениями на подключение к базе данных и контролирую таймауты. Для обращений к Redis/Memcached также важны низкие сетевые задержки и таймауты. Я использую трассировку в приложении для распознавания и сокращения количества запросов N+1 - это снижает нагрузку на обработчик и бэкенд одновременно.
В условиях жесткой конкуренции это часто имеет смысл, написание разделение процессов (очередей, асинхронных заданий) и доступа к чтению в кэше. Это позволяет сократить время выполнения внешних запросов и уменьшить вариативность времени отклика.
Аспекты контейнеров, chroot и ОС
Любой, кто использует FPM или LSAPI в контейнеринг позволяет добиться гибкости в использовании версий и ограничений. Правильные ограничения, эффективный планировщик процессов и подходящие квоты процессора/памяти очень важны. Слишком жесткие квоты приводят к задержкам в P99. В классических установках chroot/jail или изоляция пользователей с помощью пространств имен помогают строго разделить доступ к файлам. Я держу образы на минимуме, чтобы сократить время холодного старта (например, после развертывания) и разогреть пулы перед переключением трафика.
Ротация журналов и Противодавление-Стратегии обязательны: полные диски или блокирующие записи журналов напрямую влияют на время отклика. Я также калибрую стратегии swappiness, HugePages (где это уместно) и NUMA на хостах с большим количеством ядер, чтобы рабочие не замедлялись из-за доступа к памяти на разных узлах.
Работающие устройства LSAPI и FPM
LSAPI выигрывает от стабильных, долговечных процессов и эффективной диспетчеризации запросов. Я регулирую максимальное количество запросов на одного рабочего, чтобы ограничить эффект утечки памяти и контролировать перезапуски в режиме реального времени. В FPM я выбираю по требованию для сайтов с нерегулярным трафиком, динамический Я определяю pm.max_requests так, чтобы спорадические утечки или фрагментация не играли роли. Я устанавливаю request_slowlog_timeout достаточно близко, чтобы рано распознать реальные зависания, но не настолько близко, чтобы сложные операции администратора постоянно били тревогу.
Для обоих миров я проверяю Сигнальные пути для перезагрузки и определять пути эскалации, если рабочие не перезапускаются без проблем. Это позволяет избежать сбоев в работе платформы при развертывании в середине дня.
Контрольный список: Выбор и настройка на практике
- Определите цель: максимальная Совместимость (FPM) против минимальной хвостовой задержки (LSAPI) против очень жесткого разделения (CGI).
- Уточните роль сервера: Настройка одного хоста (сокет Unix) или отдельные уровни (TCP) - Установите тайм-ауты/бэклог соответствующим образом.
- Пулы для каждого аккаунта/сайта: собственный UID/GID, жесткие ограничения на память, запросы и время; активируйте slowlog.
- OPcache: достаточный размер, высокий процент попадания, стратегия ревалидации подходит для развертывания; предварительная загрузка при необходимости.
- Хранение: быстрый путь для кода/кэша, размерный кэш realpath, соблюдение специальных возможностей NFS.
- БД/кэш: соединения и таймауты соответствуют pm.max_children; исключить N+1 запросы.
- Уровень кэширования: объедините обратный прокси-сервер, кэш страниц и кэш приложений; вместо "слепого" опустошения - аннулирование.
- Наблюдаемость: P95/P99, длина очереди, состояние рабочих, частота попадания в OPcache, задержки ввода-вывода и бэкенда - с первого взгляда.
- Ролики: Грациозная перезагрузка, разогрев, атомарное развертывание, выборочное аннулирование кэша.
- Планирование пропускной способности: резервы на случай прорыва, отсутствие избыточного бронирования; реалистичная оценка затрат/выгод от лицензий LSAPI.
Краткое резюме: моя классификация
Для смешанных сред хостинга PHP-FPM оптимальный баланс производительности, изоляции и совместимости. На стеках LiteSpeed LSAPI дает ощутимые преимущества в плане хвостовых задержек и потребления оперативной памяти. CGI подходит для строгого разделения в нишевых случаях, но отстает в динамичных проектах. Изначально я полагаюсь на FPM с четкими ограничениями пула, активированным OPcache и чистой настройкой веб-сервера. Если вы ожидаете большой конкуренции, протестируйте LSAPI на LiteSpeed и только потом принимайте решение. Затраты и выгоды-решение.
