Nginx или apache?

Nginx или apache?

Apache против Nginx: плюсы и минусы для WordPress

Требования к производительности WordPress могут варьироваться в зависимости от проектов, но одна вещь, безусловно, остается неизменной — она должна быть быстрой.

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

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

При выборе веб-сервера у вас есть несколько вариантов; Apache, Nginx, IIS, Caddy и Lighttpd — все популярные проекты. Мы рассмотрим Apache и Nginx в этом руководстве.

По оценкам, из всего Интернета в совокупности Apache Server и Nginx вместе составляют 50% всего веб-трафика.

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

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

Nginx

  • Начатый в 2002 году российским инженером-программистом Игорем Сысоевым в качестве решения проблемы C10k — задача для веб-серверов для обработки 10 000 одновременных подключений.
  • Выпущен публично в 2004 году, поставив цель в качестве асинхронной, неблокирующей, управляемой событиями архитектуры.
  • Легкая работа на минимальном аппаратном обеспечении обеспечивает отличную производительность статического контента.
  • Высокая чувствительность при большой нагрузке.
  • Использует конфигурационный файл nginx.conf с синтаксисом JS-типа с фигурной скобкой.
  • Расширяемость со сторонними модулями.

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

Для статического контента это работает очень быстро. Что касается динамического контента, например PHP, Nginx не имеет возможности обрабатывать это с помощью модуля, как это делает Apache. Но это не помеха, поскольку для достижения этого используется FastCGI. Это очень хорошо работает в сочетании с пулами соединений php fpm и memcache.

Требования WordPress

  • PHP 7>
  • MySQL 5.6 или Maria DB 10.0>
  • Mod_rewrite (при использовании Apache)
  • SSL (если используется)

Оба Apache и Nginx поддерживают php fpm. Это менеджер FastCGI, forked process manager для PHP, который может использоваться для обеспечения очень быстрого времени отклика. Выполняясь как демон на сервере, он будет инициализировать процессы, как только они потребуются.

Настройка PHP FPM с помощью Apache

Пользователи Ubuntu и Debian могут устанавливать необходимые пакеты с помощью aptitude через:

sudo apt-get -y install libapache2-mod-fastcgi php7.0-fpm php7.0

Теперь включите модуль в apache:

a2enmod actions fastcgi alias

Затем в файле конфигурации /etc/apache2/conf-available/php7.0-fpm.conf добавьте следующее:

<IfModule mod_fastcgi.c> AddHandler php7-fcgi .php Action php7-fcgi /php7-fcgi Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization </IfModule>

Кроме того, в вашем VirtualHost для WordPress (путь по умолчанию /etc/apache2/sites-available/000-default.conf) добавьте следующее:

<Directory /usr/lib/cgi-bin> Require all granted </Directory> <IfModule mod_fastcgi.c> SetHandler php7-fcgi .php Action php7-fcgi /php7-fcgi virtual Alias /php7-fcgi /usr/lib/cgi-bin/php7-fcgi FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi -socket /var/run/php/php7.0-fpm.sock -pass-header Authorization </IfModule>

Теперь перезапустите apache, и готово

systemctl restart apache2.service

Создайте файл с содержимым вида <? php phpinfo (); ?> и откройте его в своем браузере. Теперь PHP будет работать с FPM.

Теперь проверьте свой блог WordPress. Обратили внимание на разницу?

Настройка PHP FPM с Nginx

Пользователи Ubuntu и Debian могут установить пакет следующим образом:

apt-get -y install php7.0-fpm

Теперь в вашем файле конфигурации (по умолчанию /etc/nginx/sites-available/default) в блоке сервера вам необходимо добавить конфигурацию FastCGI следующим образом:

server { … location / { # use try files to try and serve the file try_files $uri $uri/ =404; } # PHP FPM Configuration location ~ \.php$ { include snippets/fastcgi-php.conf; # Connect via socket fastcgi_pass unix:/run/php/php7.0-fpm.sock; } # deny apache .htaccess requests location ~ /\.ht { deny all; } … }

Здесь мы используем фрагмент из Nginx, чтобы установить параметры cgi и передать fastcgi соединение сокета.

Затем убедитесь, что вы установили cgi.fix_pathinfo = 0 в php ini, поскольку настройка по умолчанию нарушает конфигурацию. Измените /etc/php/7.0/fpm/php.ini и установите:

; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. PHP’s ; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok ; what PATH_INFO is. For more information on PATH_INFO, see the cgi specs. Setting ; this to 1 will cause PHP CGI to fix its paths to conform to the spec. A setting ; of zero causes PHP to behave as before. Default is 1. You should fix your scripts ; to use SCRIPT_FILENAME rather than PATH_TRANSLATED. ; http://php.net/cgi.fix-pathinfo cgi.fix_pathinfo=0

Теперь вы можете сохранить файл и перезагрузить PHP FPM. Сделайте это через:

service php7.0-fpm reload

Наконец, мы можем проверить <? phpinfo (); ?> в своем браузере, чтобы подтвердить, что сервер теперь использует PHP FPM с Nginx.

Выполнение mod_rewrite в Nginx

Nginx не использует файл .htaccess, а для перезаписи URL он использует гораздо более простой подход.

Чтобы ваш блог WordPress работал с Nginx, просто добавьте следующее к части try_files вашей конфигурации Nginx:

location / { index index.php index.html index.htm; try_files $uri $uri/ /index.php?q=$uri&$args; }

Если вы используете каталог для своего блога WordPress, задайте следующее:

location /wordpress/ { try_files $uri $uri/ /index.php?q=$uri&$args; }

Перезапустите Nginx, и у вас будет работать перезапись URL.

$ service nginx restart

Оптимальные настройки

У вас есть много вариантов оптимизации WordPress посредством кеширования на сервере с помощью memcache, varnish, а также на уровне приложения WordPress с помощью плагинов, которые легко позволят вам получить доступ к этому.

Однако то, что предлагает Nginx, — отличное решение для обслуживания статического контента веб-сайта с его надежным и быстрым статическим кешем содержимого.

Кэш статического содержимого

Nginx очень быстро работает в качестве кеша статического содержимого, и именно там его использование действительно впечатляет в WordPress и сообщениях в блогах с большим количеством изображений. Вы можете обслуживать свои CSS, JS и изображения через сервер Nginx, работающий именно для этих нужд.

Лучше всегда делать это в домене без файлов cookie, чтобы контент был действительно кэширован браузером (поскольку cookie не кэшируются), поэтому использование субдомена, такого как images.myblog.com или static.myblog.com, будет идеально.

Блок местоположения для этой конфигурации статических субдоменов будет выглядеть так:

location ~* ^.+\.(?:css|cur|js|jpe?g|gif|htc|ico|png|html|xml|otf|ttf|eot|woff|svg)$ { access_log off; expires 30d; tcp_nodelay off; ## Set the OS file cache. open_file_cache max=3000 inactive=120s; open_file_cache_valid 45s; open_file_cache_min_uses 2; open_file_cache_errors off; }

Используя open_file_cache, мы включаем кеширование для наших статических медиафайлов. Мы указываем максимальное количество файлов для кэширования и как долго их следует хранить с помощью open_file_cache max=3000 inactive=120s;

Если вы хотите настроить кеширование по всему проекту, просто добавьте следующие четыре строки в свои конфигурации nginx.conf:

open_file_cache max=10000 inactive=5m; open_file_cache_valid 2m; open_file_cache_min_uses 1; open_file_cache_errors on;

Важно: open_file_cache_errors будет кэшировать фактические ошибки 404, поэтому лучше отключить это, если вы используете балансировщик нагрузки.

Пулы подключения PHP-FPM

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

Вы можете настроить несколько конфигураций, например:

/etc/php-fpm.d/family-site.conf /etc/php-fpm.d/travel-blog.conf /etc/php-fpm.d/cooking-recipes.conf

В каждом из следующих вариантов мы можем установить множество конфигураций:

listen = 127.0.0.1:9000 user = user group = websites request_slowlog_timeout = 5s slowlog = /var/log/php-fpm/slowlog-site.log listen.allowed_clients = 127.0.0.1 pm = dynamic pm.max_children = 5 pm.start_servers = 3 pm.min_spare_servers = 2 pm.max_spare_servers = 4 pm.max_requests = 200 listen.backlog = -1 pm.status_path = /status request_terminate_timeout = 120s rlimit_files = 131072 rlimit_core = unlimited catch_workers_output = yes env = $HOSTNAME env = /tmp env = /tmp env = /tmp

С помощью этого вы можете указать параметры конфигурации PHP-FPM, такие как pm.max_children, и вы также можете указать переменные окружения и установить здесь параметры имени пользователя и группы.

Балансировщик нагрузки Nginx

Если вы собираетесь получать много трафика, то вам, вероятно, захочется настроить балансировщик нагрузки для использования с настройкой php-fpm.

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

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

Примерная конфигурация будет выглядеть так. Сначала мы начинаем с модуля upstream:

upstream backend { server backend1.example.com; server backend2.example.com; server backend3.example.com; }

Здесь каждый backend1.example.com имеет собственную конфигурацию Nginx, зеркало того, как сайт был до того, как он имел балансировщик нагрузки. Nginx будет выбирать, какой сервер использовать для каждого запроса.

Если у одного из наших бэкендов есть более быстрый жесткий диск, например SSD, или географически ближе к вашей основной пользовательской базе, вы можете установить вес так:

upstream backend { server backend1.example.com weight=1; server backend2.example.com weight=2; server backend3.example.com weight=4; }

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

upstream backend { server backend1.example.com max_fails=3 fail_timeout=15s; server backend2.example.com weight=2; server backend3.example.com weight=4;

Теперь, с этой конфигурацией, после 3 сбоев или 15-секундного таймаута сервер больше не будет использоваться балансировщиком нагрузки. Если вы хотите вручную пометить сервер как неактивный, добавьте ключевое слово down например так: server backend3.example.com down;.

Затем нам нужно передать это серверу через прокси-сервер, используя backend upstream, который мы только что определили ранее:

server { location / { proxy_pass http://backend; } }

Теперь перезагрузите сервер с помощью service nginx restart, и вы запускаете балансированную по нагрузке версию своего сайта!

Наконец, по этой теме, также для вашей справки приведено руководство nginx по обслуживанию статического содержимого и наилучшим параметрам конфигурации. Обратите внимание на использование tcp_nopush и sendfile для Mp3, например.

Вывод

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

Миграция вашего WordPress в Nginx не очень сложна, и конфигурация для Nginx, очень проста и удобна в доступе по сравнению с Apache.

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

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

В будущем, возможно, больше хостов примет инструменты Nginx cPanel, такие как Engintron, которые также предоставляют Nginx для cPanel.

Nginx или Apache

О чем речь

  1. Apache и Nginx: основные различия
  2. В чём два решения не равны
  3. Какой из них выбрать?

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

Программное обеспечение Apache и Nginx: основные различия.

Лицензирование.

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

Оба серверных приложения являются бесплатными. Но в отличие от (свободного) Apache, у Nginx есть коммерческая версия под названием Nginx Plus. В библиотеке модулей, доступных для Nginx (включая модули сторонних разработчиков), некоторые модули не являются бесплатными.

Производительность.

Общеизвестно, что Nginx работает очень хорошо. Он не перегружает систему. Секрет этой скорости — событийная архитектура и асинхронность.

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

Вполне закономерный вопрос от начинающего веб-мастера: «почему многие крупные сайты и порталы перешли на Nginx?». Выскажу сугубо личное мнение. Некоторое время назад у Apache были небольшие проблемы с утечкой памяти, а также повышенная нагрузка на программный ресурс. Поддержка и мониторинг, а также стоимость дополнительных гигабайтов памяти, подталкивали разработчиков к поиску менее затратных и более надежных путей. Nginx как нельзя кстати подошел для решения задачи. Параллельные соединения в одном процессе, отсутсвие перманентных обращений к .htaccess во всех каталогах при каждом запросе к серверу, оптимальное потребление памяти, балансировщик нагрузки, проксирующий-сервер … уже только это сыграло в пользу Nginx. Кстати, в большинстве случаев его ставили перед Апачем как балансировщик нагрузки и для отдачи статики, то есть в роли backend-а был всё равно Apache.

Модульность программного обеспечения Apache и Nginx

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

В чём два решения не равны.

Apache полностью модульный. Добавление и удаление необходимых модулей делается очень просто (команда активации/деактивации модуля + команда для перезагрузки Apache).

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

Nginx не грантирует обратную совместимость с предыдущими версиями. Так что в случае, если вы установили новую версию с новыми модулями, настройки взаимодействия с сайтом придется менять почти полностью.

Итак, какой из них выбрать?

Зависит от целей конкретного проекта.

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

Во всех случаях e107 CMS успешно работает на любом из этих серверных приложений.

Для взаимодействия с Apache в системе e107 CMS уже изначально предустановлены все необходимые файлы, в том числе .htaccess

Для взаимодействия с Nginx системе e107 CMS не требуются дополнительные настройки, кроме настроек самого Нджинкса.

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

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

Общая информация

Прежде чем мы перейдем к более детальному сравнению Apache vs Nginx давайте рассмотрим общие характеристики этих веб-серверов.

Веб-сервер Apache был разработан Робертом МакКулом в 1995 году под руководством Apache Software Foundation. С 1999 и по сей день Apache — это проект Apache Software, и сейчас это одна из самых популярных их программ.

Начиная с 1996 года Apache был самым популярным веб-сервером на просторах интернета. Из-за такой популярности веб-сервер имеет много документации и комплексную поддержку со стороны других компаний.

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

В 2002 году Игорь Сусоев начал работу над веб-сервером Nginx, он поставил перед собой цель решить проблему десяти тысяч подключений, которой были подвержены все известные на то время веб-серверы. Дело в том, что ни один из существующих веб-серверов, не позволял обрабатывать 10 тысяч запросов одновременно. Первый публичный релиз состоялся в 2004 году и цель была достигнута, благодаря реализации архитектуры, основанной на асинхронных событиях.

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

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

Отличия архитектуры

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

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

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

Каждый процесс потребляет оперативную память, поэтому MPM будет сложно использовать на слабом оборудовании. Но он по-прежнему может быть отличным выбором при работе с определенными компонентами. Например, php не поддерживает потоки, поэтому это единственный способ безопасной работы с mod_php.

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

mpm_event — этот модуль похож на mpm-worker, только оптимизирован для работы с keep-alive соединениями. При обработке в mpm-worker соединение будет держать поток занятым независимо от того активно оно или нет. mpm_event позволяет отдавать отдельные потоки для keep-alive соединений, так чтобы они не мешали работать другим потокам.

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

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

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

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

Генерация контента

С точки зрения использования в реальных сценариях наиболее часто выполняется сравнение Nginx или Apache при обработке динамического и статического контента

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

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

Это означает, что нужно настроить соединение между Nginx и одним из интерпретаторов. Nginx поддерживает такие протоколы FastCGI, SCGI, uWSGI, memcache. Это может немного усложнить ситуацию, особенно при попытке предвидеть количество соединений.

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

Отличия настройки

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

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

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

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

Nginx не поддерживает интерпретацию .htaccess файлов или любой другой механизм настройки вне основного конфигурационного файла. Такой вариант менее гибкий, но у него есть свои преимущества.

Работа без .htaccess выполняется намного быстрее, потому что не нужно ничего сканировать, проверять каждый каталог, читать и интерпретировать несколько файлов для каждого запроса. Nginx будет обслуживать запросы быстрее. Второе преимущество — это безопасность, веб-сервер будут контролировать только привилегированные пользователи, а значит меньше вероятность допустить ошибку.

Отличия определения путей

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

Apache интерпретирует запросы как физические ресурсы в файловой системе или в качестве местоположения документа. Для файлов используются теги <Directory> и <FIles>, а для более абстрактного местоположения — <Location>.

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

Когда запрос не соответствует файлу есть несколько альтернатив, например, директива Alias может быть использована для указания альтернативного местоположения. Директива <location> позволяет превратить любой URL адрес в адрес файловой системы с помощью регулярных выражений. Но все же Apache больше рассчитан на работу с файлами.

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

Основные блоки — это server и location, первый указывает какой хост запрашивается, а второй проверяет соответствие частей URL по регулярному выражению.

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

Такой подход позволяет более просто функционировать в роли веб-сервера и прокси одновременно. Вам нужно только указать как реагировать на определенные типы запросов.

Модули

Оба севера Nginx и Apache поддерживают расширение возможностей через модули, но реализация очень сильно отличается.

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

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

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

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

Но здесь модули тоже очень полезны, они позволяют сильно расширить функциональность программы. Они более безопасны, так как произвольные компоненты не могут быть включены. Модули Nginx позволяет делать то же что и в Apache: проксирование, ограничение скорости, аутентификацию, шифрование, потоковая передача и многое другое.

Нужен ли nginx для node.js сервера?

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

Масштабируемость

Работать с одной-единственной нодой получится только до тех пор, пока на сервере находится один-единственный сайт. Однако в моей практике такого не было почти никогда: я как минимум ставлю ещё Munin для наблюдения за состоянием сервера. Придётся или вешать сайт на отдельный порт/айпишник (неудобно), или дописывать в ноде код для проксирования запросов на другой сайт (замусоривание кода всякими сложностями). В то время как в nginx новый сайт легко подключить парой строчек в конфиге.

Ещё один пример — A/B тестирование: запускаем две разные версии сайта, половину пользователей направляем на одну версию сайта, половину на другую, сравниваем их поведение и решаем, какая версия сайта лучше. Если изменения значительные, то скорее всего придётся запустить две ноды, и опять же нужно каким-то чудом решать, какой пользователь на какую ноду будет отправлен. Опять же в nginx это делается парой строчек (split_clients).

Когда сайт станет большой и популярный, нода может перестать помещаться в одном процессе или одном сервере, и придётся запускать несколько экземпляров ноды или даже докупать новые серверы. nginx позволит равномерно распределить нагрузку между процессами/серверами, принимая все запросы на себя и пересылая его на один из случайно выбранных процессов/серверов (или не случайно — смотря как настроить).

Безопасность

Использовать стандартные порты 80/443 может только root. А когда код сайта запускается от рута, это ОЧЕНЬ плохо: малейшая RCE-уязвимость — и злоумышленник без проблем получает полный доступ к серверу. Если нода будет работать от рута, то малейшая уязвимость в коде сайта может позволить с лёгкостью получить контроль над сервером целиком (как с помощью RCE, так и с помощью чтения какого-нибудь ../../../../../../etc/shadow и последующего подбора пароля от рута в оффлайне, например).

В идеале код должен быть максимально изолирован от всего (вплоть до помещения в изолированный Docker-контейнер (ходят слухи, что докер ещё и для разработки и развёртывания очень удобен, но я не верю)). Если нода будет изолирована от всех, то максимум, что получит злоумышленник — контроль над нодой. Ну и доступ к базе данных, если она используется. Это плохо, но не совсем плохо, потому что взломанную ноду можно просто выключить до исправления уязвимости. А вот выпнуть злоумышленника, получившего root, будет уже гораздо тяжелее (вплоть до необходимости отключения сервера от интернета и полной переустановки системы).

Но, допустим, вы перекостыляли с роутингом или форками или пропатчили ядро или ещё что-то и в итоге каким-то чудом умудрились поднять ноду на порту 80/443 без root. Тогда пришло время вспомнить про HTTPS и сертификаты для него. Для работы SSL/TLS ноде нужен будет доступ к приватному ключу, и опять же, если злоумышленник откопает RCE-уязвимость, то он сможет прочитать приватный ключ и начать организовывать MitM-атаки. Если же HTTPS будет настроен на nginx и доступ к приватному ключу будет только у nginx, то злоумышленник обломается. (Хотя, конечно, налажать могут всегда и везде, даже у nginx+openssl однажды утекали приватные ключи… поэтому переходим на libressl)

Кроме того, есть ряд менее серьёзных атак, которые всё же могут подпортить нервы. Например, манипуляции с медленными HTTP-запросами. В nodejs была уязвимость CVE-2013-4450, позволяющая завалить её HTTP pipelining запросами и тем самым скушать ресурсы сервера. Теоретически подобное, конечно, может найтись и в nginx, но всё же сама его архитектура неплохо спасает от подобных пакостей. При наличии nginx на ноду уже будут приходить белые и пушистые HTTP-запросы, доставляющие минимум проблем, в то время как всякий мусор будет отфильтрован или забуферизован самим nginx’ом. (Хотя от терабитных DDoS-атак ничего не спасёт, но не будем о грустном)

Прочие плюшки

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

Про вебсокеты

Непонятно, что у вас за проблемы были — без подрбоностей понять, кто виноват и что делать, трудно; у меня всё проксируется через nginx вполне стабильно. А пинги должны быть в любом случае, потому что отвалиться по таймауту может что угодно где угодно даже не на вашем сервере (например, мобильный оператор Теле2 обрубает TCP-соединения после пяти минут бездействия). «Городить свой пинг-понг» не нужно, потому что эта фича встроена в протокол — не знаю, как именно вы реализуете вебсокеты в ноде, но пинги где-то там наверняка уже должны быть.

slonik_v_domene

Наступивший январь порадовал нас очередным сравнением теплого с мягкимApache vs Nginx как платфом для работы с PHP.
Перед тем как комментировать заметку рекомендую все же дочитать ее до конца и осилить разбор полетов. Если желания читать нет, краткая суть: автор сравнения провел тесты неверно, без понимания сути происходящего. К реальности все его выводы не имеют никакого отношения вовсе.
Теперь объяснение, почему так.
Я потрудился перепроверить полученные результаты на собственном стенде.
Выбранная система — Ubuntu 12.04.3 LTS, ядро — Linux 3.8.0-29-generic x86_64. Установка проведена методом «Yes -> Yes -> Ok -> Restart».
Из стандартных репозиториев были доустановлены пакеты:

apache2-mpm-prefork 2.2.22-1ubuntu1.4 libapache2-mod-php5 5.3.10-1ubuntu3.9 nginx-full 1.1.19-1ubuntu0.5 php5-fpm 5.3.10-1ubuntu3.9
Хотя в этом и не было никакого смысла (один-единственный отдаваемый файл и так был бы закеширован) по настоятельной просьбе был создан Ram-disk размером 64М:mkfs -q /dev/ram1 65536 mount /dev/ram1 /opt/www/example.com
Конфигурация сервисов:
/etc/nginx/sites-available/example.comserver { listen 8080; root /opt/www/example.com/htdocs; index index.html; server_name example.com; location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; } # location / # { # proxy_pass http://127.0.0.1:80/; # } }
Для тестирования nginx+Apache/mod_php использовалась закомментированная часть файла конфигурации.
/etc/php5/fpm/pool.d/www.confpm.max_children = 250 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 10 pm.max_requests = 0
/etc/apache2/apache2.conf<IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 250 MaxRequestsPerChild 0 </IfModule>
/etc/apache2/sites-available/example.com<VirtualHost *:80> ServerName example.com ServerAlias www.example.com DocumentRoot /opt/www/example.com/htdocs <Directory /> Options FollowSymLinks AllowOverride None </Directory> ErrorLog ${APACHE_LOG_DIR}/example.com-error.log CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined </VirtualHost>
Если вы не видите в списке значение какого-либо параметра, значит оно оставлено без изменений из конфигурации «по умолчанию».
Сам файл:
/opt/www/example.com/htdocs/index.php
<?php for($i = 0; $i < 1000; ++$i) { echo «Hello, World! $i «; }
Тесты проведены утилитой ab с различной конкурентностью. Проводилось пять замеров, два самых медленных результата отбрасывались, данные по остальным трем замерам осреднялись. Стоит отметить, что при использовании php-fpm количество переданных данных было меньше из-за разницы в количестве передаваемых данных по протоколу FastCGI. Так как разница в объеме трафика составила около 1%, этим расхождением можно смело пренебречь.
Чтобы исключить сайд-эффекты от недостатка памяти и вычислительной мощности, тестирование велось на сервере с заведомо достаточным количеством оперативной памяти и CPU.
Apache:Total transferred: 180820000 bytes HTML transferred: 178900000 bytes
Nginx:Total transferred: 180490000 bytes HTML transferred: 178900000 bytes
Concurrency Level: 10 Apache: 1407.41 Nginx/fpm-unix: 1108.12 Nginx/fpm: 1102.07 Nginx/apache: 1040.58
Concurrency Level: 50 Apache: 1273.71 Nginx/fpm-unix: 1106.68 Nginx/fpm: 1083.58 Nginx/apache: 1009.34
Concurrency Level: 100 Apache: 1288.83 Nginx/fpm-unix: 1095.26 Nginx/fpm: 1085.20 Nginx/apache: 989.68
Concurrency Level: 200 Apache: 1054.37 Nginx/fpm-unix: 1045.21 Nginx/fpm: 993.68 Nginx/apache: 978.78
Мы видим следующие вещи:
1) при возрастании конкурентности уменьшаются как разница в результатах, так и скорость ответа
2) nginx в любой конфигурации при небольшой и средней конкурентности медленнее apache/mod_php
3) nginx+fpm через unix socket быстрее nginx+fpm через tcp socket
4) nginx+apache/mod_php работает сопоставимо с nginx+fpm
На этом статью можно было бы закончить и дать всем желающим возможность сделать далеко идущие очевидные и при этом неправильные выводы. Тем не менее, я прокомментирую полученные результаты.
Почему так и с какой стати nginx работает медленее?
При использовании nginx+fpm мы имеем два разных сервера: nginx на порту 8080 и fpm на порту 9000. Нетрудно догадаться, что nginx работает как прокси для сервера fpm, сначала принимая запрос извне и затем отправляя его к серверу fpm по протоколу FastCGI. Если же используется apache/mod_php, запросы обрабатываются непосредственно на сервере без проксирования куда-либо.
Очевидно, что при всех тех же самых условиях двузвенная система (ab <-> apache) будет работать быстрее чем трехзвенная (ab <-> nginx <-> fpm), отсюда и полученные результаты.
Если же мы используем unix socket, накладные расходы на транспортировку данных между nginx и fpm уменьшаются, причем особенно хорошо это заметно при большой конкурентности. Это и понятно — unix socket по сути — двунаправленный пайп, фактически, данные копирутся из одного буфера в другой без задействования сетевой подсистемы.
Почему при увеличении конкуренции разница уменьшается?
Потому, что становится важным тот факт что система тратит ресурсы на шедулинг процессов (и fpm и apache создают необходимое количество процессов для обработки запросов), а также то, что возрастает вычислительная нагрузка на процессор и систему виртуальной памяти — на это тоже тратятся ресурсы.
Стоит ли отказаться от Nginx-fpm в пользу Apache/mod_php?
Короткий ответ: Да. Нет. В зависимости от задач.
Длинный ответ: даже в самом простом случае кроме запуска PHP требуется отдавать и статику (html, css, js, картинки и т.п). Nginx с этой задачей справляется куда как лучше чем Apache. Кроме того, nginx в состоянии одновременно обслуживать очень большое количество подключений, что также недоступно в случае использования Apache. Поэтому роль nginx как правило заключается балансировке нагрузки, отдаче статики, проксированию запросов к PHP на внутренние сервера, а самое главное — к работе с медленными клиентами. В этом случае логично поднять php-fpm и обрабатывать запросы к php через него.
Если же требуется сложная работа с реврайтами, дополнительными модулями apache, фильтрами содержимого и подобными вещами и это требуется делать вместе с модулем php, имеет смысл поставить Apache/mod_php. При этом вы должны очень хорошо понимать, что вы делаете и какой результат хотите получить.
Выставлять ничем не прикрытый Apache в мир, прочтя англоязычную статью и захотев получить прирост 1-10% по скорости ответа — очень, очень плохая идея. Не делайте так.
Менее очевидный вывод
Apache, как парзер протокола HTTP и запускальщик модулей, написан хорошо. В нем с его архитектурой «один-процесс-на-одного-клиента» практически нечего улучшать, поэтому все его альтернативы (например, php-fpm) работают с сопоставимой скоростью. В ряде задач требуется именно такой подход (например, для обработки изображений «на лету»), поэтому Apache с соответствующим модулем — хороший и правильный выбор.
Любителям «оптимизаций»
Чудес не бывает. Все сервера с архитектурой вида «1 запрос — 1 процесс» ведут себя практически одинаково: у них сопоставимые скорости работы и примерно похожее поведение под возрастающей нагрузкой. Выбор конечного решения должен основываться не на мифическом приросте производительности в 6-10%, а прежде всего на технологическом удобстве (удобстве разработки, деплоймента, необходимости дополнительной обработки запроса и т.п.)
Спасибо за внимание.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *