Nginx или Apache: производительность, настройка и сценарии

Короткий ответ

Для нового проекта чаще выбирают Nginx: он быстро отдаёт статику, экономно держит много соединений и отлично работает обратным прокси перед приложением.

Apache остаётся разумным выбором, если проект завязан на .htaccess, использует специфичные модули Apache или живёт на shared-хостинге, где у вас нет доступа к главному конфигу.

Модели обработки соединений

Apache: MPM

Apache обрабатывает запросы через MPM (Multi-Processing Modules):

• prefork — отдельный процесс на каждое соединение. Надёжно, совместимо со старым PHP-модулем mod_php, но тяжело по памяти.
• worker — процессы с несколькими потоками внутри.
• event — развитие worker: простаивающие keep-alive соединения обслуживаются отдельно, что заметно экономит ресурсы.

Nginx: цикл событий

Nginx изначально построен на асинхронной событийной модели: небольшое число worker-процессов, каждый обслуживает множество соединений без блокировок. При большом числе одновременных и медленных клиентов потребление памяти растёт гораздо мягче.

.htaccess против центрального конфига

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

• Плюс: удобно на shared-хостинге и для CMS, которые сами пишут правила (WordPress, многие PHP-фреймворки).
• Минус: Apache проверяет эти файлы во всех папках по пути запроса при каждом запросе, это лишняя работа. Правила разбросаны по проекту, их сложнее отлаживать.

Nginx не поддерживает .htaccess. Вся конфигурация — в центральных файлах, применяется через reload.

• Плюс: быстрее, предсказуемее, легче проверять и хранить в Git.
• Минус: нужен доступ к серверу, а правила из .htaccess придётся переписать вручную.

Статика и динамика

Ключевое отличие: Apache может выполнять PHP внутри себя (mod_php), а Nginx всегда передаёт динамику внешнему процессу. Современная практика для обоих — PHP-FPM.

Когда нужна связка Nginx перед Apache

Схема: Nginx принимает все запросы, сам отдаёт статику и HTTPS, а динамические запросы проксирует на Apache.

Она оправдана, когда:

• у вас старое PHP-приложение, сильно завязанное на .htaccess и модули Apache, и переписывать правила дорого;
• нужно быстро разгрузить Apache от статики и медленных клиентов;
• вы постепенно переезжаете на Nginx и хотите делать это по частям.

Минусы связки: два сервера в цепочке, два набора конфигов и логов, больше точек отказа. Для нового проекта она обычно не нужна.

Как выбрать

• Новый проект, SPA, API на Node.js/Python/Go — Nginx как обратный прокси.
• WordPress или другой PHP-проект на своём сервере — Nginx + PHP-FPM, правила переписываются один раз.
• Shared-хостинг, .htaccess обязателен — Apache.
• Легаси, который сложно трогать — Nginx перед Apache как промежуточный этап.

Частые ошибки

• Копировать правила .htaccess в Nginx дословно — синтаксис и логика разные.
• Оставлять Apache на prefork без причины, когда event подходит лучше.
• Строить связку двух серверов «для скорости» там, где хватило бы одного Nginx.