nginx или apache что лучше
Apache против Nginx: плюсы и минусы для WordPress
Другое требование, которое само собой разумеется, производительность должна быть экономичной, поэтому у нас не может быть ресурсоемких решений. Решения должны быть скромными, средними и надежными и полностью максимизировать доход на вашем сайте, расходы на хостинг должны быть сведены к минимуму.
Если вы ожидаете получить большой трафик, конфигурация веб-сервера, в которой вы используете WordPress, напрямую влияет на производительность вашего сайта, что влияет на время загрузки и стабильность.
По оценкам, из всего Интернета в совокупности Apache Server и Nginx вместе составляют 50% всего веб-трафика.
Отличия
Основное различие заключается в том, как обрабатываются соединения.
Проще говоря, Apache использует разветвленное многопоточное решение или keep-alive, которое поддерживает соединение для каждого пользователя.
С другой стороны, Nginx использует неблокирующий цикл событий, который объединяет соединения, работающие асинхронно через рабочие процессы.
Из-за этой архитектуры результатом является однопоточный процесс nginx, и для обработки каждого нового соединения не создаются дополнительные процессы. Таким образом, даже при высокой нагрузке, CPU и оперативная память не очень сильно расходуются при таком подходе.
Помимо архитектуры, есть также некоторые незначительные различия и нюансы между ними в конфигурации, и мы рассмотрим их более подробно позже в этом руководстве.
Во-первых, давайте посмотрим на два проекта и сделаем четкий обзор.
Apache
Nginx
Будучи преемником Apache, Nginx имеет преимущество в понимании ошибок и проблем производительности параллелизма, которые могут произойти благодаря его очень быстрой асинхронной схеме цикла событий.
Для статического контента это работает очень быстро. Что касается динамического контента, например PHP, Nginx не имеет возможности обрабатывать это с помощью модуля, как это делает Apache. Но это не помеха, поскольку для достижения этого используется FastCGI. Это очень хорошо работает в сочетании с пулами соединений php fpm и memcache.
Требования WordPress
Оба Apache и Nginx поддерживают php fpm. Это менеджер FastCGI, forked process manager для PHP, который может использоваться для обеспечения очень быстрого времени отклика. Выполняясь как демон на сервере, он будет инициализировать процессы, как только они потребуются.
Настройка PHP FPM с помощью Apache
Пользователи Ubuntu и Debian могут устанавливать необходимые пакеты с помощью aptitude через:
Теперь включите модуль в apache:
Затем в файле конфигурации /etc/apache2/conf-available/php7.0-fpm.conf добавьте следующее:
Кроме того, в вашем VirtualHost для WordPress (путь по умолчанию /etc/apache2/sites-available/000-default.con f) добавьте следующее:
Теперь перезапустите apache, и готово
Создайте файл с содержимым вида и откройте его в своем браузере. Теперь PHP будет работать с FPM.
Теперь проверьте свой блог WordPress. Обратили внимание на разницу?
Настройка PHP FPM с Nginx
Пользователи Ubuntu и Debian могут установить пакет следующим образом:
Теперь в вашем файле конфигурации (по умолчанию /etc/nginx/sites-available/default) в блоке сервера вам необходимо добавить конфигурацию FastCGI следующим образом:
Здесь мы используем фрагмент из Nginx, чтобы установить параметры cgi и передать fastcgi соединение сокета.
Затем убедитесь, что вы установили cgi.fix_pathinfo = 0 в php ini, поскольку настройка по умолчанию нарушает конфигурацию. Измените /etc/php/7.0/fpm/php.ini и установите:
Теперь вы можете сохранить файл и перезагрузить PHP FPM. Сделайте это через:
Наконец, мы можем проверить в своем браузере, чтобы подтвердить, что сервер теперь использует PHP FPM с Nginx.
Выполнение mod_rewrite в Nginx
Чтобы ваш блог WordPress работал с Nginx, просто добавьте следующее к части try_files вашей конфигурации Nginx:
Если вы используете каталог для своего блога WordPress, задайте следующее:
Перезапустите Nginx, и у вас будет работать перезапись URL.
Оптимальные настройки
У вас есть много вариантов оптимизации WordPress посредством кеширования на сервере с помощью memcache, varnish, а также на уровне приложения WordPress с помощью плагинов, которые легко позволят вам получить доступ к этому.
Кэш статического содержимого
Nginx очень быстро работает в качестве кеша статического содержимого, и именно там его использование действительно впечатляет в WordPress и сообщениях в блогах с большим количеством изображений. Вы можете обслуживать свои CSS, JS и изображения через сервер Nginx, работающий именно для этих нужд.
Блок местоположения для этой конфигурации статических субдоменов будет выглядеть так:
Если вы хотите настроить кеширование по всему проекту, просто добавьте следующие четыре строки в свои конфигурации nginx.conf:
Важно: open_file_cache_errors будет кэшировать фактические ошибки 404, поэтому лучше отключить это, если вы используете балансировщик нагрузки.
Пулы подключения PHP-FPM
Вы можете настроить несколько конфигураций, например:
В каждом из следующих вариантов мы можем установить множество конфигураций:
С помощью этого вы можете указать параметры конфигурации PHP-FPM, такие как pm.max_children, и вы также можете указать переменные окружения и установить здесь параметры имени пользователя и группы.
Балансировщик нагрузки Nginx
Если вы собираетесь получать много трафика, то вам, вероятно, захочется настроить балансировщик нагрузки для использования с настройкой php-fpm.
Обычно мы хотим запустить несколько бэкенд серверов на верхнем уровне, все из которых работают с зеркалами вашего блога, а затем еще один сервер, на котором работает nginx, который действует как балансировщик нагрузки и будет направлять нагрузку между потоками трафика.
Это означает, что вы можете использовать много серверов для одновременного доступа к вашему блогу, а конфигурация для этого относительно проста.
Примерная конфигурация будет выглядеть так. Сначала мы начинаем с модуля upstream:
Здесь каждый backend1.example.com имеет собственную конфигурацию Nginx, зеркало того, как сайт был до того, как он имел балансировщик нагрузки. Nginx будет выбирать, какой сервер использовать для каждого запроса.
Если у одного из наших бэкендов есть более быстрый жесткий диск, например SSD, или географически ближе к вашей основной пользовательской базе, вы можете установить вес так:
Кроме того, если вы считаете, что сервер может стать медленнее или вы беспокоитесь о тайм-аутах, то для этого тоже есть варианты конфигурации:
Затем нам нужно передать это серверу через прокси-сервер, используя backend upstream, который мы только что определили ранее:
Наконец, по этой теме, также для вашей справки приведено руководство nginx по обслуживанию статического содержимого и наилучшим параметрам конфигурации. Обратите внимание на использование tcp_nopush и sendfile для Mp3, например.
Миграция Apache в Nginx
Помимо чтения руководства Nginx и самостоятельного внесения изменений, вы можете использовать инструмент apache2nginx с открытым исходным кодом для перевода вашей конфигурации с Apache на Nginx.
Следуйте инструкциям по установке apache2nginx README, и после установки вы сможете перенести файлы конфигурации, просто выполнив:
Теперь вы можете проверить конфигурацию и попробовать ее в установке Nginx. Вы можете обнаружить, что перевод не был совершенным, но он даст вам основание для начала.
Вывод
Для скорости и производительности Nginx является очевидным выбором вместо Apache, но это не означает, что Apache не может обрабатывать некоторый трафик. Если вы планируете перейти на первую страницу Reddit в ближайшее время, вероятно, вам стоит взглянуть на получение более эффективного решения с Nginx и PHP-FPM.
Миграция вашего WordPress в Nginx не очень сложна, и конфигурация для Nginx, очень проста и удобна в доступе по сравнению с Apache.
Хотя там и нет модулей, подобных Apache, и вначале это может быть незнакомо, вы сможете найти им замену в большинстве случаев. Если нет, то в качестве резервного решения вы всегда можете проксировать старый сервер через ваш nginx для этой цели, если это необходимо.
Существует множество способов настройки обоих серверов, поэтому хорошее решение можно найти почти всегда, независимо от требований. На данный момент кажется, что Apache всегда будет выбором по умолчанию для широко доступного хостинга cPanel, благодаря инструменту настройки EasyApache, который поставляется вместе с ним.
В будущем, возможно, больше хостов примет инструменты Nginx cPanel, такие как Engintron, которые также предоставляют Nginx для cPanel.
На данный момент, если вы хотите переключиться на WordPress с поддержкой Nginx, вам нужно будет настроить Linux VPN на DigitalOcean, AWS или на другом хостинг-провайдере.
NGINX vs Apache: Сравнение двух популярных веб-серверов
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и NGINX. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент NGINX (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины NGINX был создан для преодоления ограничений производительности веб-серверов Apache. NGINX, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут как автономный веб-сервер и как внешний прокси-сервер для Apache и других веб-серверов.
Обзор Apache
Модель «один сервер делает все» стала ключом к успеху Apache. Однако по мере увеличения уровней трафика и увеличения количества веб-страниц работа Apache стала усложняться.
Обзор NGINX
NGINX также имеет богатый набор функций и может выполнять различные роли сервера :
Apache против Nginx: сравнение наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
NGINX, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей NGINX должны быть очень осторожны, чтобы создавать эффективный и точный код, без каких-либо сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим.
Давайте рассмотрим эти два понятия:
Статический контент
Динамический контент
Результаты тестов Speedemy показали, что производительность динамического контента была одинаковой для серверов Apache и NGINX. Вероятная причина этого заключается в том, что почти все время обработки запросов тратится в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере без необходимости полагаться на внешние компоненты. Эти динамические процессы могут быть включены с помощью динамически загружаемых модулей.
NGINX изначально не имеет возможности обрабатывать динамический контент. Для обработки PHP и других запросов на динамический контент NGINX должен перейти на внешний процессор и дождаться отправки отрендеренного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его накладные расходы будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. NGINX также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и NGINX являются безопасными веб-серверами. Команда безопасности Apache существует, чтобы предоставлять помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках. Существует множество рекомендаций по обеспечению безопасности серверов для предотвращения атак безопасности.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долгое время имел динамическую загрузку модулей, поэтому все модули Apache поддерживают это.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживается обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был долгое время популярен, поддержка сервера довольно распространена повсеместно.
Наряду с документацией многие веб-проекты содержат инструменты для начальной загрузки в среде Apache. Оно может быть включено в сами проекты или в пакеты, поддерживаемые вашим дистрибутивом.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности его доступности.
Ngnix против Apache: Сравнение лицом к лицу
Apache
Ngnix
Совместное использование NGINX и Apache
Итак, что вы выберете? Apache или NGINX?
Как видно, Apache и NGINX являются мощными, гибкими и производительными веб-серверами. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше подходит для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
Apache vs Nginx: практический взгляд
Введение
Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.
Несмотря на то, что у Apache и Nginx много схожих качеств, их нельзя рассматривать как полностью взаимозаменямые решения. Каждый из них имеет собственные преимущества и важно понимать какой веб-сервер выбрать в какой ситуации. В этой статье описано то, как каждый из этих веб-серверов ведет себя при различных условиях.
Общий обзор
Прежде чем погрузиться в различия между Apache и Nginx давайте бегло взглянем на предысторию каждого из этих проектов.
Apache
Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.
Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.
Администраторы часто выбирают Apache из-за его гибкости, мощности и широкой распространенности. Он может быть расширен с помощью системы динамически загружаемых модулей и исполнять программы на большом количестве интерпретируемых языков программирования без использования внешнего программного обеспечения.
Nginx
В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.
Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.
Администраторы часто выбирают Nginx из-за его эффективного потребления ресурсов и отзывчивости под нагрузкой, а также из-за возможности использовать его и как веб-сервер, и как прокси.
Архитектура обработки соединений
Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.
Apache
Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:
Nginx
Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов.
Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие.
Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла.
Этот подход к обработке соединений позволяет Nginx’у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках.
Статический и динамический контент
Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.
Apache
Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.
Apache также может раздавать динамический контент встраивая интерпретатор нужного языка в каждого воркера. Это позволяет обрабатывать запросы к динамическому содержимому средствами самого веб-сервера и не полагаться на внешние компоненты. Интерпретаторы языков могут быть подключены к Apache с помощью динамически загружаемых модулей.
Возможность обрабатывать динамический контент средствами самого Apache упрощает конфигурирование. Нет необходимости настраивать взаимодействие с дополнительным софтом, динамический модуль может быть легко отключен в случае изменившихся требований.
Nginx
Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.
Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx’у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.
Однако, этот метод имеет и свои преимущества. Так как интерпретатор не встроен в каждого воркера, то оверхед, связанный с этим, будет иметь место только при запросах к динамическому контенту. Статический контент будет возвращен клиенту простым способом и запросы к интерпретатору будут выполняться только тогда когда они нужны. Apache тоже может работать в такой манере, но тогда это лишит его всех преимуществ описанных в предыдущем разделе.
Распределенная конфигурация против централизованной
Для администраторов одним из очевидных отличий этих двух веб-серверов является наличие у Apache возможности задавать конфигурацию на уровне директории.
Apache
Это дает простой способ таким приложениям как системы управления контентом (CMS) конфигурировать собственное окружение не имея доступа к конфигурационному файлу веб-сервера. Это также может быть использовано шаред хостингами, чтобы сохранить контроль над основным конфигурационным файлом и дать клиентам контроль над конфигурацией определенных директорий.
Nginx
Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).
Второе преимущество связано с безопасностью. Распределенная конфигурация на уровне директорий в Apache возлагает ответственность за безопасность на обычных пользователей, которые вряд ли способны решить эту задачу качественно. То что администратор контролирует весь сервер предотвращает ошибки безопасности, которые могут возникнуть если дать пользователям доступ к конфигурации.
Интерпретация базирующаяся на файлах и URI
То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.
Apache
Так как Apache изначально был спроектирован как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы в файловой системе. Он берет document root веб-сервера и дополняет его частью запроса, которая следует за именем хоста и номером порта, чтобы найти запрашиваемый файл. В общем случае, иерархия файловой системы представленная в вебе доступна как дерево документов.
Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.
Nginx
Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.
В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.
Модули
И Apache, и Nginx могут быть расширены при помощи системы модулей, но способы реализации модульной системы принципиально отличаются.
Apache
Система модулей Apache позволяет динамически загружать и выгружать модули, чтобы удовлетворить ваши потребности, в то время как ваш сервер запущен. Ядро Apache всегда доступно, в то время как модули можно включать и выключать, чтобы добавить или удалить функциональность из основного сервера.
Apache использует эту функциональность для решения широкого круга задач. Благодаря зрелости платформы существует огромное множество модулей, которые могут изменять ключевые особенности сервера, например модуль mod_php позволяет включать PHP-интерпретатор в кажого воркера.
Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL’ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.
Nginx
Nginx тоже имеет систему модулей, но она сильно отличается от подхода используемого в Apache. В Nginx модули загружаются не динамически, а должны быть выбраны и скомпилированы с ядром сервера.
Для многих пользователей по этой причине Nginx кажется менее гибким. Это особенно относится к пользователям, кто имеет мало опыта ручной сборки приложений и предпочитают использовать системы управления пакетами. Обычно разработчики дистрибутивов стремятся создать пакеты для всех часто используемых модулей, но если вам нужен какой-то нестандартный модуль вам придется собрать его из исходников самостоятельно.
Тем не менее, модули в Nginx очень полезны и востребованы, вы можете определить чего вы хотите от сервера и включить только те модули, что вам нужны. Некоторые пользователи считают такой подход более безопасным так как произвольные модули не могут быть подключены к серверу.
Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL’ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.
Поддержка, совместимость, экосистема и документация
В процессе использования приложения важными являются экосистема созданная вокруг него и возможность получения поддержки.
Apache
Так как Apache пользуется популярностью такое длительное время с поддержкой у него нет проблем. Легко можно найти большое количество документации как от разработчиков Apache, так и от сторонних авторов. Эта документация покрывает все возможные сценарии использования Apache, включая взаимодействие с другими приложениями.
Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.
Nginx
Nginx обычно используется там, где предъявляются повышенные требования к производительности и в некоторых областях он все еще является догоняющим.
В прошлом было сложно найти вменяемую поддержку по этому веб-серверу на английском языке, так как на ранних этапах разработка и документация велись на русском языке. Вместе с ростом интереса к проекту документация была переведена на английский и теперь можно найти достаточное количество документации и от разработчиков веб-сервера, и от сторонних авторов.
Разработчики стороннего ПО также начинают поддерживать работу с Nginx и некоторые из них уже предлагают на выбор пользователя конфиги для работы или с Apache, или с Nginx. И даже без поддержки приложением работы с Nginx не составляет большого труда написать свой конфиг для интеграции приложения с Nginx.
Совместное использование Apache и Nginx
После того как вы ознакомились с плюсами и минусами Apache и Nginx у вас должно появиться представление того, какой из серверов больше подходит под ваши задачи. Однако, можно достигнуть лучших результатов используя оба сервера вместе.
Распространенной схемой использования является размещение Nginx перед Apache в качестве реверс-прокси. В такой конфигурации Nginx называют фронтендом, а Apache — бэкендом. При таком подходе Nginx будет обслуживать все входящие запросы клиентов и мы получим выигрыш из-за его возможности обрабатывать множество конкурентных запросов.
Nginx будет самостоятельно обслуживать статический контент, а для динамического контента, например для запросов к PHP-страницам, будет передавать запрос к Apache, который будет рендерить страницу, возвращать ее Nginx’у, а тот в свою очередь будет передавать ее пользователю.
Такая конфигурация очень популярна, Nginx используется в ней для сортировки запросов. Он обрабатывает сам те запросы которые может и передает Apache только запросы, которые не может обслужить сам, снижая таким образом нагрузку на Apache.
Эта конфигурация позволяет горизонтально масштабировать приложение: вы можете установить несколько бэкенд серверов за одним фронтендом и Nginx будет распределять нагрузку между ними, увеличивая тем самым отказоустойчивость приложения.
Заключение
Как вы можете видеть и Apache, и Nginx — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.
Между этими проектами есть значительные различия, которые могут оказать влияние на производительность, возможности и время реализации необходимое для внедрения и запуска каждого из решений. Выбор является серией компромиссов и не стоит пренебрегать тестами. В конечном итоге, не существует одного универсального веб-сервера под все возможные задачи, поэтому важно найти решение максимально соответствующее вашем задачам и целям.