Что быстрее apache или nginx
Записки bаckend-разработчика
10 отличий Apache от Nginx
Доброго времени суток, backend/frontend/full-stack/devops/qa/.. да какая разница, добро пожаловать, мой друг!
Начнем с архитектурных и функциональных отличий.
1. Метод обработки соединений с клиентами
Nginx состоит из master-процесса и нескольких дочерних процессов. Мастер процесс обычно один — он создает дочерние процессы (воркеры, загрузчик кеша и кеш менеджер), считывает конфигурацию и открывает порты. Воркеров обычно несколько, разработчики nginx советуют количество воркеров определять равным числу ядер машины. Эти дочерние процессы буду обслуживать все соединения с клиентами в неблокирующей манере. В nginx используется бесконечный цикл, который бежит по всем соединениями и отвечает на запросы клиентов. Когда соединение закрывается, оно удаляется из event loop. Это решение идеально подходит для проектов, которые обслуживающих 10к+ соединений одновременно. При этом, загрузка CPU и использование памяти обычно равномерны, без видимых пиков.
2. Отдаваемый контент
Apache — может генерировать как статический контент, так и динамический. С этим никаких проблем нет. Прекрасно подойдет тем, кто не хочет заморачиваться с проксированием и настройкой дополнительного инструмента для генерации динамики, ведь Apache — это готовое работающее решение.
Nginx — отдает только статику и из коробки генерировать динамический контент не умеет. Если вы используете nginx и хотите генерировать динамический контент на своем сайте, то вам придется проксировать запросы тому, кто это делать умеет (apache, php-fpm и др.). Поэтому, разработчикам придется настраивать дополнительную связку, которая усложняет архитектуру, например nginx+apache (кстати в этой связке, Apache называют бекенд сервером, а Nginx — фронтендом), nginx + phpfpm, nginx + python и др.
3. Конфигурирование
Nginx не поддерживает конфигурирование на уровне каталогов. Существует один конфигурационный файл на весь проект, который обрабатывает master. Если вы хотите обновить конфигурацию, то необходимо отправить сигнал SIGHUP мастеру, который в свою очередь перезагружает конфигурацию и плавно завершает работу воркеров.
4. Работа с модулями
Apache за долгое время существования обзавелся около 60 официальными модулями, и еще большим числом неофициальных. Модули динамически подключаются, не требуют сборки и перезагрузки веб-сервера.
Nginx имеет около 130 официальных модулей. В отличие от Apache, модули Nginx не могут быть динамически загружены на лету и требуют сборки. Это гораздо сложнее, но считается безопаснее.
5. Интерпретация запросов
Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки.
Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.
6. Работа со скриптовыми языками
В Apache есть один модуль mod_php и все хосты вынуждены работать с одной и той же версией php и одним конфигурационным файлом.
В случае с nginx, каждый виртуалхост будет выполняться в отдельном процессе и, соответственно, может использовать разные версии php (python/ruby/perl и др.). Каждый процесс может иметь свою собственную независимую конфигурацию.
Вообще, в высоконагруженных проектах удобнее держать раздельно nginx и php. По отдельности их проще мониторить, ловить баги или узкие места. «Все-в-одном» Apache+mod_php в этом плане менее удобен.
От основных архитектурных и функциональных отличий переходим к показательным отличиям, отличиям инфрастктуры и всего того, что также является не менее важным при выборе веб-сервера.
7. Скорость работы
Скорость работы веб-сервера обычно измеряют для 2-х случаев отдачи контента: для статики и динамики. На основе тестов производительности, Nginx примерно в 2.5 раза быстрее отдает статику, чем Apache. Это довольно-таки большое превосходство. Если вам необходимо обслуживать большое количество статического контента, Nginx — лучший выбор. Во время тестирования отдачи динамического контента, Apache и Nginx показывают примерно одинаковые результаты. С точки зрения памяти, оба сервера используют один и тот же объем ресурсов. (Подробнее о тестах скорости отдачи контента можно почитать здесь)
8. Поддержка ОС
Apache прекрасно работает на Unix-подобных операционных системах, также разработчики этого веб-сервера полностью поддерживают линейку Microsoft Windows, включая последние версии этой ОС.
Nginx также поддерживает работу на множестве Unix-подобных ОС и имеет некоторую поддержку Windows, которая не является полной. Но разве кто-то в наше время размещает веб-сервер на Windows?
9. Сообщество и поддержка
Apache на рынке с 1995 года, что очень немалый срок, обеспечивший инструменту огромное сообщество и поддержку с его стороны. Практически на все вопросы на Stack Overflow уже есть исчерпывающие ответы. Коммерческой поддержки нет.
Nginx веб-сервер более молодой, на рынке он с 2004 года, что также не помешало большому сообществу сформироваться и поддерживать друг друга. Nginx, в отличие от Apache, имеет коммерческую версию Nginx Plus, которая дополнена инструментами балансировки нагрузки, мониторинга, потоковой передачи медиа и др.
10. Документация и обучение
И у Apache и у Nginx присутствует доступная официальная документация.
Nginx предлагает платное обучение, включающее в себя онлайн курсы, практические занятия и экзамен. По окончании курса все участники получают сертификаты. Например, сдать экзамен по основам nginx и получить официальный сертификат обойдется в 49$ (подробнее здесь).
От себя хотелось бы отметить, что оба решения очень стабильны, безопасны и поддерживаемы. Выбирайте то, что подходит именно вам. Пробуйте, экспериментируйте, ошибайтесь и снова пробуйте. Всем добра и будьте здоровы!
Производительность 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 это бесконечная тема.
Пожалуйста, оставьте ваши мнения по текущей теме статьи. За комментарии, отклики, лайки, подписки, дизлайки огромное вам спасибо!
Дайте знать, что вы думаете по этой теме статьи в комментариях. Мы крайне благодарны вам за ваши комментарии, лайки, дизлайки, отклики, подписки!
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 или на другом хостинг-провайдере.