LAMP, LEMP или Nginx + Apache: какой веб-стек выбрать

LAMP и LEMP — два классических набора программ для сайтов на PHP: Linux, веб-сервер, база данных и PHP. Отличаются они веб-сервером: в LAMP это Apache, в LEMP — Nginx. На практике важнее другое — как именно веб-сервер запускает PHP. От этого зависят расход памяти, поведение под нагрузкой и то, нужен ли вам второй веб-сервер.

Из чего состоит стек

Вместо MySQL в обоих стеках можно использовать PostgreSQL — большинство современных PHP-приложений это поддерживают. Название стека от этого не меняется.

Как Apache выполняет PHP

У Apache есть два способа запустить PHP.

mod_php. Интерпретатор PHP встроен прямо в процессы Apache. Это самый простой вариант, но он плохо сочетается с многопоточными моделями Apache. Сторонние расширения PHP не всегда потокобезопасны, поэтому с mod_php обычно используют модель обработки (MPM) prefork. По документации Apache, prefork — «не многопоточный сервер с заранее запущенными процессами», и он подходит сайтам, которым нужно избегать потоков из-за библиотек, не рассчитанных на многопоточность. Каждый процесс обслуживает одно соединение, поэтому при сотне одновременных посетителей нужна сотня процессов, и в каждом — полный интерпретатор PHP, даже если запрошена картинка.

PHP-FPM. PHP работает отдельной службой со своим пулом процессов, а Apache передаёт ей запросы через модуль mod_proxy_fcgi. Тогда Apache может работать в модели event: по документации, после отправки ответа рабочий поток передаёт соединение отдельному потоку-слушателю, и простаивающие keep-alive-соединения не занимают рабочие потоки. Статику Apache отдаёт сам, не трогая PHP.

Минимальная связка Apache и PHP-FPM через сокет:

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

Путь к сокету зависит от версии PHP и дистрибутива. Отсюда главный вывод: утверждение «Apache создаёт процесс на каждый запрос» верно только для prefork. Apache с event и PHP-FPM по устройству близок к Nginx с PHP-FPM.

Как Nginx выполняет PHP

Nginx не умеет выполнять PHP сам — встроенного модуля нет. Он всегда передаёт PHP-запросы в PHP-FPM по протоколу FastCGI, а статику отдаёт напрямую. Минимальная конфигурация:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Файл snippets/fastcgi-php.conf есть в пакетах Debian и Ubuntu; в других дистрибутивах нужные параметры FastCGI задают вручную.

Главное практическое различие — .htaccess

Apache читает файлы .htaccess в каталогах сайта: там правила перенаправлений, защита каталогов, настройки кеширования. Многие CMS, прежде всего WordPress и Bitrix, рассчитывают на этот механизм и записывают в .htaccess свои правила. Nginx .htaccess не читает: всё задаётся в конфигурации сервера, и после изменений её нужно перечитывать.

Для администратора это плюс — конфигурация в одном месте и не проверяется на каждом запросе. Для владельца сайта на готовой CMS это может быть проблемой: правила из .htaccess придётся переносить в конфигурацию Nginx вручную, а при обновлении плагинов — следить, чтобы ничего не потерялось.

Гибрид: Nginx перед Apache

В гибридной схеме Nginx принимает соединения на портах 80 и 443, завершает HTTPS, сам отдаёт статику и передаёт остальные запросы Apache, который слушает внутренний порт, например 127.0.0.1:8080. Сайт при этом продолжает пользоваться .htaccess.

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

На стороне Apache нужен модуль mod_remoteip, чтобы в журналах и в приложении был виден настоящий адрес посетителя, а не 127.0.0.1. Приложение должно понимать заголовок X-Forwarded-Proto, иначе при HTTPS на входе оно может уйти в бесконечный редирект на HTTPS.

Эту схему по умолчанию используют многие панели управления хостингом. Подробнее об обратном прокси на Nginx и о том, как выбрать между Nginx, Apache, HAProxy, Caddy и Traefik, — в статье «Caddy vs. Traefik vs. HAProxy vs. Nginx vs. Apache».

Когда что выбирать

Гибрид оправдан, когда нужен .htaccess. Если сайт от него не зависит, второй веб-сервер — это лишняя память, лишний уровень, где может сломаться конфигурация, и лишний пакет для обновлений.

Типичные ошибки

• mod_php с моделью event. Пакеты Debian и Ubuntu при установке libapache2-mod-php переключают Apache на prefork. Если потом вручную включить event, Apache может отказаться запускаться или работать нестабильно. С event используйте PHP-FPM.
• MaxRequestWorkers не по памяти. В prefork каждый процесс занимает десятки мегабайт. Документация Apache прямо говорит: значение должно быть достаточно большим для ожидаемой нагрузки и достаточно маленьким, чтобы всем процессам хватило оперативной памяти. Иначе сервер уходит в своп.
• Apache в гибриде слушает внешний интерфейс. Порт 8080 должен быть доступен только с 127.0.0.1, иначе к сайту можно обратиться в обход Nginx.
• Разные версии PHP в пулах. У каждой версии PHP-FPM свой сокет; проверьте, что веб-сервер указывает на нужный.
• Статика через PHP. Если все запросы, включая картинки, уходят в PHP-FPM, сервер тратит ресурсы впустую. Правила для статики должны стоять раньше правила для PHP.