чем 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 — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.
Между этими проектами есть значительные различия, которые могут оказать влияние на производительность, возможности и время реализации необходимое для внедрения и запуска каждого из решений. Выбор является серией компромиссов и не стоит пренебрегать тестами. В конечном итоге, не существует одного универсального веб-сервера под все возможные задачи, поэтому важно найти решение максимально соответствующее вашем задачам и целям.
Производительность Nginx vs Apache: методы оптимизации
Nginx был выпущен в 2004 году. Сначала он использовался в качестве дополнения к Apache. Но его популярность неуклонно растет.
Apache существует уже давно, и для него доступен большой набор модулей. Известно, что управление серверами Apache удобно для пользователя. Динамическая загрузка модулей позволяет компилировать и добавлять различные модули в стек Apache без перекомпиляции двоичного файла главного сервера.
Подобная гибкость еще не доступна для Nginx. Из руководства по настройке Nginx для HTTP/2 становится ясно, что его модули настраиваются во время сборки.
Nginx не только не имеет эквивалентного решения, но и препятствует его внедрению из-за снижения производительности.
Доли рынка для различных серверов в 1995–2005 гг.
LiteSpeed — это один из претендентов, который можно сравнить с Apache. Но он лишен проблем с производительностью.
Это делает LiteSpeed серьезным конкурентом, ориентированным на хостинг-провайдеров, уделяющих внимание производительности. Но он также может использоваться для небольших серверов или сайтов.
Вопросы аппаратного обеспечения
Какое бы из этих решений мы ни выбрали, наличие достаточного объема ОЗУ имеет большое значение. Когда процесс веб-сервера не имеет достаточного объема оперативной памяти, он начинает использовать файл подкачку. Он подразумевает использование жесткого диска или SSD для расширения оперативной памяти. В результате увеличивается время ожидания при каждом обращении к этой памяти.
Мониторинг
Htop является одним из эффективных способов мониторинга текущей производительности стека серверов.
Monit — еще один инструмент с открытым исходным кодом, который позволяет контролировать систему. В нем можно настроить отправку оповещений, перезапуск определенных процессов или перезагрузку системы при выполнении заданных условий.
Тестирование системы
После установки Locust нужно будет создать файл locust в каталоге, из которого вы запускаете приложение:
Затем запускаем инструмент из командной строки:
Применение перечисленных выше средств создает эффект DDoS-атаки, поэтому рекомендуется ограничить тестирование собственными сайтами.
Настройка Apache
MPM-модули Apache
Вначале своего существования Apache создавал новый процесс для каждого входящего TCP-соединения и ответа на него. Если появлялись другие соединения, создавались другие рабочие процессы для их обработки.
Чтобы снизить затраты ресурсов, разработчики Apache создали режим prefork с заранее заданным числом процессов. Но встроенные динамические языковые интерпретаторы в каждом процессе все равно потребляли много ресурсов, Поэтому сбои в работе серверов Apache с настройками по умолчанию стали распространенным явлением.
Тест Locust, который показывает порождение огромного числа процессов Apache для обработки входящего трафика.
Этот режим является основной причиной плохой репутации Apache. Его использование может привести к неэффективному распределению ресурсов.
Модуль worker реализует гибридный режим работы, основанный на потоке процессов. Согласно официальному сайту Apache :
Этот режим использует ресурсы более эффективно.
В версии Apache 2.4 появился модуль событий. Он добавляет отдельный поток прослушивателя, который управляет бездействующими соединениями после завершения HTTP-запроса. Это неблокирующий асинхронный режим, потребляющий меньший объем памяти.
Мы загрузили тестовую установку WooCommerce с 1200 записями на виртуальном сервере и протестировали ее на Apache 2.4 со стандартным режимом, prefork и mod_php.
Сначала мы протестировали его в libapache2-mod-php7 и mpm_prefork_module на https://tools.pingdom.com:
Затем мы провели тестирование MPM модуля событий. Нам нужно было добавить multiverse в /etc/apt/sources.list :
После этого мы выполнили sudo apt-get update и установили libapache2-mod-fastcgiphp-fpm :
Поскольку php-fpm — это служба, отдельная от Apache, требуется выполнить ее перезапуск:
Затем мы отключили модуль prefork, включили режим событий и proxy_fcgi:
После чего добавили следующий фрагмент кода к виртуальному хосту Apache:
Директива MaxRequestWorkers устанавливает ограничение на количество одновременных запросов. Значение, не равное нулю, предотвращает возможную утечку памяти.
Другие советы по настройке Apache
Выдержка из документации Apache:
Решение заключается в том, чтобы отключить этот файл в /etc/apache2/apache2.conf :
Nginx
Настройки Nginx
Nginx рекомендует привязывать количество потоков workers к количеству ядер процессора, установив в /etc/nginx/nginx.conf для worker_processes значение auto (по умолчанию используется значение 1).
Keepalive-соединения также влияет на производительность.
Согласно официальному сайту Nginx :
HTTP keepalive-соединения — это необходимая функция производительности, которая снижает задержку и позволяет быстрее загружать веб-страницы.
Workers Nginx могут обрабатывать тысячи входящих соединений одновременно. Если Nginx применяется в качестве обратного прокси-сервера, то он использует локальный пул keepalive-соединений без издержек TCP-соединения.
Параметр keepalive_requests устанавливает количество запросов, которые клиент может выполнить через одно keepalive-соединение.
Параметр keepalive_timeout устанавливает время, в течение которого keepalive- соединение остается открытым.
Включение входящих keepalive-соединений требует помещения этих директив в основную конфигурацию Nginx:
Если интерфейсное приложение продолжает опрашивать фоновое приложение о наличии обновлений, увеличение значений keepalive_requests и keepalive_timeout ограничит число соединений, которые необходимо установить.
Значение директивы keepalive не должно быть слишком большим, чтобы позволить другим соединениям достигнуть вышестоящего сервера.
Использование unix сокетов
По умолчанию Nginx использует отдельный процесс PHP, в который он перенаправляет запросы PHP-файлов. В этом он действует как прокси.
Установка виртуального хоста с Nginx будет выглядеть так:
FastCGI — это протокол, отличный от HTTP. Поэтому первые две строки передают аргументы и заголовки в php-fpm. Третья строка указывает способ проксирования запроса — через сокет локальной сети.
Это удобно для многосерверных установок, поскольку мы можем указать удаленные серверы для проксирования запросов.
Но если мы размещаем всю установку в одной системе, нужно использовать Unix сокет для подключения к процессу прослушивания php:
gzip_static : общепринятая рекомендация относительно производительности сервера заключается в необходимости сжатия статических ресурсов. Но нужно пытаться сжимать только файлы, размер которых превышает установленное значение. Так как сжатие ресурсов на лету при каждом запросе может быть ресурсозатратным.
Кеширование с помощью Nginx
Включить кеширование в Nginx довольно просто.
levels определяет количество уровней каталогов, в которых Nginx должен хранить кэшированное содержимое.
max_size не является обязательным параметром и устанавливает верхний предел для размера кэшируемого содержимого. В нашем случае это 10 ГБ.
inactive указывает, как долго содержимое может оставаться в кэше без запроса, прежде чем оно будет удалено Nginx.
После этого также следует указать строку с именем зоны памяти либо в блоке server или в блоке location :
Дополнительный уровень надежности достигается путем указания Nginx обслуживать элементы из кэша, когда он сталкивается с ошибкой сервера в источнике:
Директивы proxy_cache_* предназначены для статических ресурсов. Но чаще нужно кэшировать динамический вывод веб-приложений. В этом случае мы будем использовать следующую директиву:
Последняя строка устанавливает заголовки ответа, чтобы сообщить нам, был ли контент доставлен из кэша или нет.
Затем в блоке server или location можно установить исключения для кэширования. Например, если строка запроса присутствует в URL-адресе:
Также в блоке server при использовании PHP мы добавляем следующий код:
Заключение
Мы рассмотрели несколько методов улучшения производительности веб-сервера. Достижение наилучших результатов в Apache и Nginx осуществляется путем тестирования и анализа конкретных случаев. Поэтому Nginx или Apache это бесконечная тема.
Пожалуйста, оставьте ваши мнения по текущей теме статьи. За комментарии, отклики, лайки, подписки, дизлайки огромное вам спасибо!
Дайте знать, что вы думаете по этой теме статьи в комментариях. Мы крайне благодарны вам за ваши комментарии, лайки, дизлайки, отклики, подписки!
Ordnung muß sein. Ordnung über alles (18+)
Инструменты пользователя
Инструменты сайта
Боковая панель
Навигация
Линкшэринг
socialite Display:icon facebook twitter
ALARM!
Добавить новую страницу
Реклама
Apache vs Nginx: Расставим точки над ё.
Наступивший январь порадовал нас очередным сравнением теплого с мягким Apache vs Nginx как платфом для работы с PHP.
Перед тем как комментировать заметку рекомендую все же дочитать ее до конца и осилить разбор полетов. Если желания читать нет, краткая суть: автор сравнения провел тесты неверно, без понимания сути происходящего. К реальности все его выводы не имеют никакого отношения вовсе.
Теперь объяснение, почему так.
Из стандартных репозиториев были доустановлены пакеты:
Хотя в этом и не было никакого смысла (один-единственный отдаваемый файл и так был бы закеширован) по настоятельной просьбе был создан Ram-disk размером 64М:
/etc/nginx/sites-available/example.com
Для тестирования nginx+Apache/mod_php использовалась закомментированная часть файла конфигурации.
/etc/php5/fpm/pool.d/www.conf
/etc/apache2/apache2.conf
/etc/apache2/sites-available/example.com
Если вы не видите в списке значение какого-либо параметра, значит оно оставлено без изменений из конфигурации «по умолчанию».
Сам файл:
/opt/www/example.com/htdocs/index.php
Тесты проведены утилитой ab с различной конкурентностью. Проводилось пять замеров, два самых медленных результата отбрасывались, данные по остальным трем замерам осреднялись. Стоит отметить, что при использовании php-fpm количество переданных данных было меньше из-за разницы в количестве передаваемых данных по протоколу FastCGI. Так как разница в объеме трафика составила около 1%, этим расхождением можно смело пренебречь.
Чтобы исключить сайд-эффекты от недостатка памяти и вычислительной мощности, тестирование велось на сервере с заведомо достаточным количеством оперативной памяти и CPU.
Apache:
Nginx:
Concurrency Level: 10
Concurrency Level: 50
Concurrency Level: 100
Concurrency Level: 200
Мы видим следующие вещи:
На этом статью можно было бы закончить и дать всем желающим возможность сделать далеко идущие очевидные и при этом неправильные выводы. Тем не менее, я прокомментирую полученные результаты.
Почему так и с какой стати nginx работает медленее?
При использовании nginx+fpm мы имеем два разных сервера: nginx на порту 8080 и fpm на порту 9000. Нетрудно догадаться, что nginx работает как прокси для сервера fpm, сначала принимая запрос извне и затем отправляя его к серверу fpm по протоколу FastCGI. Если же используется apache/mod_php, запросы обрабатываются непосредственно на сервере без проксирования куда-либо.
Очевидно, что при всех тех же самых условиях двузвенная система (ab ↔ apache) будет работать быстрее чем трехзвенная (ab ↔ nginx ↔ fpm), отсюда и полученные результаты.
Почему при увеличении конкуренции разница уменьшается?
Стоит ли отказаться от Nginx-fpm в пользу Apache/mod_php?
Короткий ответ: Да. Нет. В зависимости от задач.
Если же требуется сложная работа с реврайтами, дополнительными модулями apache, фильтрами содержимого и подобными вещами и это требуется делать вместе с модулем php, имеет смысл поставить Apache/mod_php. При этом вы должны очень хорошо понимать, что вы делаете и какой результат хотите получить.
Менее очевидный вывод
Любителям «оптимизаций»