Nginx и Apache для производительности и масштабирования

Раз в несколько месяцев меня спрашивают, не стоит ли «перейти на Nginx, чтобы сайт стал быстрее», и честный ответ обычно — нет: не потому что Nginx медленный, а потому что веб-сервер редко там, куда уходит их время. Я видел, как сайт срезал время ответа вдвое, включив OPcache и полностраничный кэш, оставшись на том же самом Apache, с которого начинал. Серверное ПО никогда не было узким местом.

Так что это не статья «кто победит», потому что в такой постановке вопрос почти не важен. Она о том, откуда на самом деле берётся производительность веб-сервера, что реально различается между Nginx и Apache и как выбирать, не превращая это в решение про бренд.

Различие, которое реально: конкурентность

Apache и Nginx обрабатывают соединения принципиально разными моделями, и это единственное место, где выбор имеет реальные последствия для производительности.

Apache в типичных конфигурациях отображает соединения на процессы или потоки. Под нагрузкой со множеством медленных или простаивающих клиентов — мобильные сети, keep-alive-соединения, долгие загрузки — каждый занимает воркер, и потребление памяти растёт с конкурентностью. Nginx использует событийно-ориентированный цикл: небольшой фиксированный набор воркер-процессов мультиплексирует тысячи соединений, а простаивающие почти ничего не стоят. Поэтому Nginx блистает как обратный прокси и при высокой конкурентности, и поэтому стал дефолтом перед API и CDN.

Для сайта, обслуживающего несколько сотен одновременных пользователей, оба комфортно быстры. Различие проявляется на хвосте — высокая конкурентность, много простаивающих соединений — а не в медианном запросе.

Слой, который важнее: как работает PHP

Когда PHP-FPM на месте, рычаги, реально двигающие производительность, в основном вообще не веб-сервер:

Для WordPress-сайта в частности полностраничный кэш (FastCGI-кэш на Nginx или плагин кэширования вроде LiteSpeed, либо за Varnish) — это разница между пересборкой каждой страницы из PHP и базы на каждый хит и отдачей статического файла за микросекунды. Это решение затмевает выбор Nginx против Apache.

Где Apache всё ещё оправдывает место: .htaccess

Подиректорные файлы .htaccess Apache — это одновременно его суперсила совместимости и тихая цена производительности. Они позволяют плагину, фреймворку или пользователю шаред-хостинга менять правила переписывания и доступа, не трогая центральный конфиг — именно поэтому так много экосистемы WordPress и legacy-PHP их подразумевает. Цена в том, что Apache проверяет наличие файлов .htaccess на каждый запрос вдоль пути. У Nginx эквивалента нет; его правила живут в одном центральном конфиге, что быстрее, но означает, что изменения требуют перезагрузки и доступа к серверу.

Если ваше приложение или хостинг зависит от .htaccess, эта зависимость — реальная причина оставить Apache в стеке, а не провал модернизации.

Nginx перед Apache: прагматичный гибрид

Выбирать не обязательно. Распространённая продакшен-форма ставит Nginx на край, а Apache за ним: Nginx терминирует TLS, отдаёт статические ассеты напрямую и обратным прокси шлёт динамические запросы Apache, который запускает приложение с нетронутой совместимостью .htaccess. Вы получаете обработку соединений и скорость статики Nginx спереди и совместимость экосистемы Apache сзади. Многие managed-хостинги WordPress запускают нечто подобное, не рекламируя это.

Практический способ выбрать

Если коротко: берите Nginx, когда нагрузка высококонкурентная, прокси-ориентированная или API-driven, и когда вы управляете конфигом сервера. Оставляйте Apache, когда зависите от .htaccess, работаете на шаред-хостинге или ваша команда уже хорошо им оперирует. А потом тратьте реальные силы на кэширование, PHP-FPM и базу — вот где выигрыши.

FAQ

Nginx быстрее Apache?

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

Использовать mod_php или PHP-FPM?

PHP-FPM почти во всех случаях. Он запускает PHP в отдельном, настраиваемом пуле воркеров, который и Apache, и Nginx используют по FastCGI, вместо встраивания интерпретатора в каждый процесс веб-сервера. Переход с mod_php на PHP-FPM обычно улучшает пропускную способность сильнее, чем смена веб-сервера.

Какой самый большой выигрыш производительности для WordPress-сайта?

Полностраничный кэш. Отдача закэшированного HTML-ответа полностью минует PHP и базу, превращая многозапросную сборку страницы в чтение статического файла. После этого OPcache и объектный кэш Redis — следующие крупнейшие выигрыши, и все они не зависят от того, Nginx у вас или Apache.

Можно ли запускать Nginx и Apache вместе?

Да, и это распространённый паттерн. Nginx стоит на краю, терминируя TLS и отдавая статику, затем обратным прокси шлёт динамические запросы Apache, который запускает приложение и сохраняет поддержку .htaccess. Вы получаете обработку соединений Nginx с совместимостью Apache.

Похожие статьи

• Docker и WordPress: как контейнеры упрощают разработку — упрощает бенчмаркинг этих серверных вариантов в воспроизводимом стеке.
• WordPress Bedrock с Docker локально и чистым PHP в продакшене — про полностраничный кэш LiteSpeed и деплой на реальном шаред-хостинге.