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

() translation by (you can also view the original English article)

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

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

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

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

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

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

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

Отличия

Основное различие заключается в том, как обрабатываются соединения.

Проще говоря, Apache использует разветвленное многопоточное решение или keep-alive, которое поддерживает соединение для каждого пользователя.

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

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

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

Во-первых, давайте посмотрим на два проекта и сделаем четкий обзор.

Apache

Начатый в 1995 году Робертом Маккулом, выпускником Университета штата Иллинойс, постоянно развивается под управлением Apache Software Foundation с 1999 года.
Наиболее широко используется в Интернете с 1996 года (по умолчанию для многих хостов, например, пользователей cPanel).
Использует широко расширяемую систему загрузки динамического модуля.
Использует файл .htaccess для перезаписи URL.
Использует файл httpd.conf для конфигурации сервера с синтаксисом типа XML.

WordPress работает с Apache довольно хорошо прямо из коробки, необходим PHP-модуль, такой как mod_php, но больше ничего не нужно.

Apache очень гибкий и имеет множество модулей. Обычно mod_rewrite используется для преобразования URL-адресов для интерпретации URL-адресов, таких как category.php?Id=4 в /categories/4.

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 через:

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

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

1	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, и готово

1	systemctl restart apache2.service

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

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

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

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

1	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.
; https://php.net/cgi.fix-pathinfo
cgi.fix_pathinfo=0
[...]

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

1	service php7.0-fpm reload

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

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

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

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

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

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

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

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

1	$ 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:

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

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

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

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

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

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

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

[site]
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] = $HOSTNAME
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /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;
}

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

1	upstream backend {
2	server backend1.example.com max_fails=3 fail_timeout=15s;
3	server backend2.example.com weight=2;
4	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, например.

Миграция Apache в Nginx

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

Следуйте инструкциям по установке apache2nginx README, и после установки вы сможете перенести файлы конфигурации, просто выполнив:

1	$ apache2nginx -f /etc/httpd/conf/httpd.conf

Теперь вы можете проверить конфигурацию и попробовать ее в установке 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 или на другом хостинг-провайдере.