Apache против NGINX: кто выигрывает с точки зрения производительности?

Apache против NGINX является одним из самых горячих споров (с момента выпуска NGINX), потому что оба они являются одними из самых распространенных веб-серверов в мире, за которыми следуют LiteSpeed ​​и OpenLiteSpeed.

Apache и NGINX поддерживают почти 60% мировых веб-сайтов. Apache и NGINX похожи с точки зрения производительности и возможностей. С другой стороны, их архитектура, безопасность и производительность различны.

Может быть сложно выбрать между этими двумя серверами, потому что они оба превосходны. Поскольку у каждого веб-сервера есть свой набор преимуществ и недостатков, крайне важно выбрать наилучший из возможных вариантов.

Вы также можете проверить дебаты openlitespeed и nginx здесь.

Сравнение скорости Apache и NGINX

Прежде чем углубляться в дебаты между Apache и NGINX. Сначала мы проведем простой тест скорости, где мы проведем тест в следующих сценариях.

• Протестируем небольшой статический файл размером 5 КБ.
• Статический файл размером 1 МБ
• Тестирование простого PHP-приложения Hello World
• Сравнительный анализ Apache и NGINX для WordPress

Мы использовали ту же процедуру для тестирования openlitespeed и nginx. OpenLiteSpeed ​​— действительно отличная альтернатива NGINX, поскольку он также поддерживает основные правила перезаписи .htaccess , поэтому вы можете легко перейти с Apache на OpenLiteSpeed.

Протестируем небольшой статический файл размером 5 КБ.

Окончательный вердикт : оба сервера работали одинаково с небольшим статическим файлом.

Апачи

Nginx

Статический файл размером 1 МБ

Окончательный вердикт : NGINX явно выиграл с большим статическим файлом.

Апачи

Nginx

Тестирование простого PHP-приложения Hello World

Окончательный вердикт : оба сервера работали одинаково с приложением hello world php.

Апачи

Nginx

Сравнительный анализ Apache и NGINX для WordPress

Окончательный вердикт : NGINX явно выиграл с сайтом на WordPress. Вы можете использовать это руководство, чтобы ускорить работу вашего магазина WooCommerce.

Апачи

Nginx

Результат тестирования — Apache против NGINX

Как мы видим в тестах, NGINX относительно лучше, чем Apache с точки зрения скорости. Результаты:

1. Протестируйте небольшой статический файл размером 5 КБ:

В этом тесте мы видим, что оба Apache и NGINX дают относительно одинаковые результаты.

2. Протестируйте большой статический файл размером 1 МБ:

В этом тесте мы видим, что скорость NGINX намного выше, чем у Apache. NGINX дает гораздо меньшее среднее время отклика.

3. Протестируйте простое PHP-приложение Hello World

В этом тесте мы видим, что и Apache, и NGINX дают относительно одинаковые результаты.

4. Тест Apache против NGINX для WordPress

В этом тесте мы видим, что среднее время отклика NGINX намного меньше, чем у Apache, что дает ему большую скорость, чем у NGINX.

Апачи

Существует сообщество разработчиков, которые поддерживают Apache как веб-сервер с открытым исходным кодом. Он использует архитектуру, управляемую процессами, где создает новый поток для каждого запроса на подключение.
Кроме того, Apache предлагает множество модулей, которые можно использовать для расширения функциональности вашего веб-сервера. Apache быстр, надежен, безопасен и легко настраивается для удовлетворения потребностей различных сред за счет использования расширений и модулей.

Архитектура обработки соединений

В Apache есть несколько многопроцессорных модулей (называемых Apache MPM), которые управляют обработкой клиентских запросов. По сути, это позволяет администраторам быстро переключать архитектуру обработки соединений.

• mpm-Prefor: этот многопроцессорный модуль (MPM) реализует предварительный разветвление веб-сервера, который не является многопоточным. Каждый серверный процесс может отвечать на входящие запросы, а размером пула серверов управляет родительский процесс. Он подходит для сайтов, которым необходимо избегать многопоточности, чтобы работать с библиотеками, которые не являются потокобезопасными. Это также лучший MPM для изоляции каждого запроса, гарантирующий, что проблема с одним не повлияет на другие.
• mpm-worker: гибридный многопроцессорный многопоточный сервер реализуется этим многопроцессорным модулем (MPM). Он может обслуживать большое количество запросов с меньшим количеством системных ресурсов, чем сервер, основанный на процессах, поскольку он использует потоки для доставки запросов. Поддерживая доступность множества процессов, каждый из которых имеет множество потоков, он сохраняет большую часть стабильности сервера, основанного на процессах.
• mpm-event: модуль многопроцессорной обработки событий (MPM) предназначен для одновременного обслуживания нескольких запросов путем делегирования определенной обработки потокам прослушивателя, освобождая рабочие потоки для обслуживания новых запросов.
  Apache имеет гибкую структуру, позволяющую выбирать из множества алгоритмов подключения и обработки запросов. Поскольку интернет-ландшафт изменился, представленные варианты в первую очередь являются результатом эволюции сервера и возросшего спроса на параллелизм.

Статический и динамический контент

Статическое содержимое может обрабатываться серверами Apache с использованием их стандартных файловых механизмов. Вышеупомянутые подходы MPM в основном отвечают за выполнение этих процедур.

Apache может дополнительно обрабатывать динамический контент, включив процессор для конкретного языка в каждый из своих рабочих экземпляров. Это позволяет ему выполнять динамический контент без использования внешних компонентов на веб-сервере. Для включения этих динамических процессоров можно использовать динамически загружаемые модули.

Поскольку Apache может обрабатывать динамический контент внутри себя, настройка динамической обработки обычно проще. Модули можно легко заменить, если требования к контенту изменятся, и связь не нужно координировать с дополнительным программным обеспечением.

Распределенная и централизованная конфигурация

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

Поскольку эти файлы расположены в папках содержимого, Apache ищет файл .htaccess в каждом компоненте пути к запрошенному файлу и применяет найденные там директивы. Это позволяет эффективно настроить децентрализованный веб-сервер, который обычно используется для перезаписи URL-адресов, ограничения доступа, авторизации и аутентификации и даже политик кэширования.

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

Некоторое веб-программное обеспечение, такое как системы управления контентом, теперь может легко настраивать свою среду, не требуя доступа к центральному файлу конфигурации. Провайдеры виртуального хостинга используют это, чтобы контролировать настройку ядра, предлагая клиентам доступ к своим конкретным каталогам.

Файл против интерпретации на основе URI

Apache может интерпретировать запрос либо как физический ресурс файловой системы, либо как назначение URI, требующее более абстрактной оценки. В общем, Apache использует блоки <Directory> или <File> для первого, тогда как блоки <Location> используются для более абстрактных ресурсов.

Поскольку Apache изначально создавался как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы файловой системы. Чтобы найти фактический файл, он начинается с корня документа и добавляет часть запроса после номера хоста и порта. В Интернете иерархия файловой системы по существу представлена ​​доступным деревом документов.

Когда запрос не соответствует базовой файловой системе, Apache предлагает несколько вариантов. Например, директиву Alias ​​можно использовать для сопоставления с другим местом. Использование блоков <Location> вместо файловой системы позволяет напрямую работать с URI. Также доступны варианты регулярных выражений для более гибкого применения конфигурации в файловой системе.

Хотя Apache может работать как с базовой файловой системой, так и с веб-пространством, он предпочитает использовать методы файловой системы. Это отражено в некоторых дизайнерских решениях, например, в использовании файлов .htaccess для настройки каждого каталога.

Модуль

Система модулей в Apache позволяет вам динамически загружать и выгружать модули в соответствии с вашими потребностями во время работы сервера. Ядро Apache присутствует всегда, но модули можно включать и выключать, добавляя или удаляя функциональность и подключаясь к основному серверу.

Эта функция используется Apache для широкого круга задач. Из-за зрелости платформы она поставляется с большой библиотекой модулей. Mod php, например, встраивает интерпретатор PHP в каждый работающий worker и может использоваться для изменения части основных функций сервера.

С другой стороны, модули не просто обрабатывают динамический контент. Они могут переписывать URL-адреса, аутентифицировать клиентов, укреплять сервер, регистрировать, кэшировать, сжимать, использовать прокси, ограничивать скорость и шифровать данные, а также выполнять другие функции. Они могут предложить расширенную функциональность, не добавляя много работы.

Поддержка, совместимость, экосистема и документация

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

Многие инструменты и веб-проекты помимо документации содержат инструменты для самозагрузки в среде Apache. Это может быть предусмотрено в самих проектах или в пакетах, поддерживаемых командой упаковки вашего дистрибутива.

Из-за его доли на рынке и времени, в течение которого он был доступен; Apache получит больше поддержки от сторонних проектов в целом. Администраторы также с большей вероятностью работали с Apache, не только из-за его широкого распространения, но и потому, что многие люди начинают свою карьеру в средах общего хостинга, где Apache используется практически исключительно из-за функций распределенного управления .htaccess .

Преимущества Apache по сравнению с NGINX

Многие веб-мастера и разработчики предпочитают Apache, а не NGINX, поскольку он намного старше. Он совместим с операционными системами Windows, Unix и Linux.

• Для подачи динамичного материала это отличное качество.
• Динамическая загрузка и выгрузка модулей.
• Предоставляет файл .htaccess для каждого каталога, который можно использовать для отмены общесистемных настроек.
• Поддержка и документация на высоте.
• В модели используется подход «одно соединение на процесс».
• Он включает модули mod_evasive и mod_security, которые добавляют дополнительный уровень безопасности.

Недостатки Apache по сравнению с NGINX

• Невозможно обрабатывать большое количество запросов одновременно.
• По сравнению с NGINX для отображения статического содержимого требуется больше времени.
• Предоставляет широкие возможности настройки и управления. В результате, это не подходит для новичков.
• Веб-сайты с большим трафиком имеют проблемы с производительностью.

Nginx

В попытке решить проблему «C10k» российский кодер Игорь Сысоев изобрел NGINX. Игорь добился своей цели: NGINX может легко управлять более чем 10 000 одновременных подключений. Чтобы лучше обрабатывать новые подключения, NGINX имеет управляемую событиями и асинхронную структуру. NGINX — это веб-сервер, который предлагает множество возможностей. Ниже перечислены некоторые из них:

• HTTP-кэш и балансировщик нагрузки.
• Внешний прокси-сервер Apache и других веб-серверов.
• Протоколы HTTP, HTTPS, SMTP, POP3 и IMAP обслуживаются этим обратным прокси-сервером.

С момента своего выпуска популярность NGINX возросла благодаря низкому использованию ресурсов и способности эффективно масштабироваться на недорогом оборудовании. NGINX — это веб-сервер, который специализируется на быстром обслуживании статического материала и предназначен для пересылки динамических запросов к программному обеспечению, которое лучше подходит для таких задач.

Архитектура обработки соединений

NGINX появился на сцене после Apache, лучше понимая проблемы параллелизма, с которыми могут столкнуться сайты в масштабе. NGINX был создан с нуля с использованием асинхронного, неблокирующего алгоритма обработки соединений, управляемого событиями, чтобы использовать эту информацию.

NGINX генерирует рабочие процессы, каждый из которых способен обрабатывать десятки тысяч соединений. Рабочие процессы достигают этого, разрабатывая механизм быстрого цикла, который регулярно проверяет и обрабатывает события. Отделяя фактическую работу от соединений, каждый работник может сосредоточиться на соединении только тогда, когда произошло новое событие.

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

NGINX может масштабироваться исключительно далеко с минимальными ресурсами благодаря своему методу обработки соединений. Поскольку сервер является однопоточным и для обработки каждого нового подключения не создаются дополнительные процессы, использование памяти и ЦП остается относительно постоянным, даже когда сервер находится под большой нагрузкой.

Статический и динамический контент

NGINX не имеет встроенной поддержки динамической обработки контента. NGINX должен передать запросы PHP и другого динамического содержимого внешнему процессору для обработки, а затем дождаться возврата обработанного содержимого. Затем клиент может быть проинформирован о результатах.

Для администраторов это означает, что связь между NGINX и процессором должна быть настроена с использованием одного из протоколов, которые понимает NGINX (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить ситуацию, особенно при оценке количества разрешенных подключений, потому что каждый вызов процессора потребует нового подключения.

Эта стратегия, с другой стороны, дает несколько преимуществ. Накладные расходы динамического интерпретатора будут присутствовать только для динамического материала, поскольку он не включен в рабочий процесс. Статическое содержимое может быть отправлено простым способом, с интерпретатором, только когда это необходимо. Это также возможно с Apache, но это устраняет преимущества, упомянутые в предыдущем разделе.

Распределенная и централизованная конфигурация

NGINX не понимает файлы .htaccess и не имеет возможности оценить конфигурацию каждого каталога вне основного файла конфигурации. Хотя он менее универсален, чем подход Apache, у него есть свои преимущества.

Повышение производительности является наиболее заметным преимуществом по сравнению с .htaccess подходом к настройке на уровне каталога. Для каждого запроса сервер будет проверять эти файлы в каждом из родительских каталогов, ведущих к запрошенному файлу в стандартной настройке Apache, которая разрешает .htaccess в любом каталоге. Если этот поиск обнаруживает один или несколько файлов .htaccess , их необходимо прочитать и обработать. NGINX может быстрее обслуживать запросы, выполняя один запрос к каталогу и читая файл для каждого запроса, не допуская переопределения каталога (при условии, что файл находится в обычной структуре каталогов).

Еще одним преимуществом является то, что это безопасно. Распределение доступа к конфигурации на уровне каталога также распределяет обязанности по обеспечению безопасности между отдельными пользователями, которым можно доверять или не доверять правильное выполнение этой задачи. Убедившись, что администратор имеет полный контроль над веб-сервером, вы можете избежать нескольких ошибок безопасности, которые могут возникнуть, когда доступ предоставляется другим.

Если вас беспокоят эти проблемы, имейте в виду, что вы можете отключить интерпретацию .htaccess в Apache.

Файл VS интерпретация на основе URI

NGINX был разработан для работы в качестве веб-сервера, а также прокси-сервера. Он работает в основном с URI, при необходимости транслируя в файловую систему из-за архитектуры, необходимой для этих двух задач.

Это видно по тому, как в некоторых случаях создаются и обрабатываются файлы конфигурации NGINX.
NGINX не имеет способа указать конфигурацию для каталога файловой системы, поэтому он анализирует URI.

Блоки server и location, например, являются наиболее важными блоками конфигурации для NGINX. Блок сервера отвечает за интерпретацию запрошенного хоста, тогда как блоки местоположения отвечают за сопоставление частей URI после хоста и порта. Теперь запрос обрабатывается как URI, а не как расположение в файловой системе.

Все запросы к статическим файлам в конечном итоге должны быть сопоставлены с местом на диске. NGINX сначала выбирает сервер и блоки местоположения, которые будут обрабатывать запрос, а затем объединяет корень документа с URI, изменяя его по мере необходимости в зависимости от настроек.

Это может показаться похожим, но интерпретация запросов в основном как URI, а не как местоположения в файловой системе, упрощает использование NGINX в качестве веб-сервера, почтового сервера и прокси-сервера. NGINX настраивается путем определения того, как он должен отвечать на определенные шаблоны запросов. NGINX не проверяет файловую систему, пока не будет готов доставить запрос, поэтому файлы .htaccess не поддерживаются.

Модули

NGINX также имеет модульную систему, однако она значительно отличается от системы Apache. Модули в NGINX нельзя загружать динамически, поэтому их необходимо выбирать и компилировать в основное программное обеспечение.
В результате NGINX станет гораздо менее адаптируемым для многих пользователей. Это особенно верно для пользователей, которые не решаются поддерживать свое собственное программное обеспечение вне стандартной схемы упаковки своего дистрибутива. Хотя пакеты большинства дистрибутивов включают в себя наиболее часто используемые модули, если вам нужен нестандартный модуль, вам придется собрать сервер самостоятельно из исходного кода.

Модули NGINX, с другой стороны, по-прежнему весьма ценны, поскольку они позволяют вам точно указать, что вы хотите от своего сервера, включая только те функции, которые вы хотите использовать. Некоторые пользователи также могут считать этот подход более безопасным, поскольку произвольные компоненты не могут быть подключены к серверу. Если ваш сервер когда-либо окажется в ситуации, когда это возможно, он почти наверняка уже скомпрометирован.

В модулях NGINX доступны многие из тех же функций, что и в модулях Apache. Поддержка прокси, сжатие, ограничение скорости, ведение журнала, перезапись, геолокация, аутентификация, шифрование, потоковая передача и почтовые функции доступны через модули NGINX.

Поддержка, совместимость, экосистема и документация

NGINX набирает популярность по мере того, как все больше людей используют его из-за его высокой производительности, но ему все еще нужно наверстать упущенное в некоторых важных областях.

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

Поддержка и документация для сторонних приложений становятся все более доступными, а сопровождающие пакетов в некоторых случаях начинают предлагать варианты автоматической настройки Apache и NGINX. Настройка NGINX для работы с другим программным обеспечением обычно проста даже без поддержки, если документированы потребности проекта (разрешения, заголовки и т. д.).

Преимущества Nginx

Веб-сервер NGINX прост, легок и быстр. Разработан специально для сайтов с высокой посещаемостью.

• Использует управляемую событиями неблокирующую архитектуру, которая использует меньше ЦП и памяти.
• Он включает в себя множество опций оптимизации и обслуживания статического контента. В результате он обслуживает статический контент в 2,5 раза быстрее и использует меньше памяти, чем Apache.
• Превосходно работает в многопроцессорной системе.
• DDoS-атаки предотвращаются встроенной опцией конфигурации.

Недостатки NGINX

• Динамический контент не может обрабатываться изначально.
• Доступно меньшее количество модулей.
• Поддерживаются операционные системы Linux и Unix, однако поддержка Windows ограничена.
• Файл .htaccess , поддерживаемый Apache, не поддерживается NGINX.
• Нехватка программного обеспечения для мониторинга журналов — просто сохраняет журналы в файлы, которые необходимо просматривать вручную.

Чтобы использовать Apache и NGINX вместе

Изучив преимущества и недостатки как Apache, так и NGINX, вы сможете определить, какой сервер больше подходит для ваших нужд. Однако многие пользователи считают, что совместное использование обоих серверов позволяет им воспользоваться преимуществами каждого сервера.

Стандартной конфигурацией для такого сотрудничества является использование NGINX в качестве обратного прокси-сервера перед Apache. Это позволит NGINX обрабатывать все запросы клиентов. Это позволяет использовать высокую скорость обработки NGINX и способность управлять большим количеством подключений одновременно.

Файлы будут доставлены быстро и напрямую клиенту для статического контента, в чем NGINX преуспевает. NGINX будет проксировать запросы динамического контента, такого как PHP-скрипты, на Apache, который будет обрабатывать результаты и предоставлять отображаемую страницу. Затем материал можно вернуть клиенту через NGINX.

Многим пользователям такая схема подходит, поскольку позволяет NGINX действовать как сортировочная машина. Он будет обрабатывать любые запросы, которые он может, и передавать те, которые он не знает, как обрабатывать. Мы можем уменьшить количество блокировок, возникающих, когда процесс или поток Apache занят, уменьшив количество запросов, которые серверу Apache предлагается обработать.

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

Когда использовать Apache против NGINX?

Как Apache, так и NGINX, как описано в этой статье, являются мощными, адаптируемыми и во всех отношениях хорошими веб-серверами. Для веб-сайтов с высокой посещаемостью Apache лучше всего подходит для предоставления динамического материала, тогда как NGINX лучше всего подходит для предоставления статического контента или медиапотоков. Это так просто:

Когда вы можете использовать Apache

• Если вы пользуетесь общим хостинг-планом.
• Если вы цените полезное сообщество с множеством ресурсов, вам сюда.
• Apache популярен среди веб-разработчиков, потому что его легко настроить.

Когда можно использовать NGINX

• Если у вас есть VPS или выделенный сервер.
• Вы владелец популярного веб-сайта с большим количеством статического контента.
• Если вы хотите управлять входящим трафиком и распределять его по более медленным вышестоящим серверам.

Apache против NGINX: какой выбрать для своего сервера в 2022 году?

Вы должны использовать тот, который предоставляет ваша хостинговая компания. Во многих случаях у вас не будет выбора. Многие веб-провайдеры придерживаются той же стратегии, которой вы должны следовать, если выбираете между Apache и NGINX:

• Apache — хороший выбор, если вы хотите разместить сервер, требующий постоянной настройки, или если вы хотите предоставить пользователям возможность настройки.
• NGINX, с другой стороны, — это то, что вам нужно, если вам нужна сверхбыстрая производительность, надежная безопасность и возможность управлять конфигурациями, а не вашими пользователями.

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

Таким образом, NGINX может быть идеальным решением, если вы полагаетесь на кэширование для хранения и обслуживания контента. Помните, что NGINX не может предоставить динамический материал; поэтому на вашу производительность будет влиять эффективность прокси-сервера, который использует ваш сервер.

Вывод

Как видите, Apache, как и NGINX, мощны, адаптируемы и функциональны. Оценка ваших индивидуальных потребностей и тестирование шаблонов, которые вы ожидаете увидеть, являются основными критериями выбора подходящего сервера.

Среди этих проектов есть существенные различия в исходной производительности, возможностях и времени, необходимом для реализации каждого из них. Однако часто они являются результатом ряда компромиссов, которые не следует игнорировать. И последнее, но не менее важное: универсального веб-сервера не существует, поэтому выберите тот вариант, который соответствует вашим потребностям.