Девять советов по улучшению производительности WordPress с NGINX

Совет 2. Кэширование динамических файлов

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

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

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

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

Чтобы включить кэширование в WordPress, используйте один из нескольких популярных плагинов — описанных ниже. Плагин кеширования WordPress запрашивает новую страницу, а затем кэширует ее в течение короткого периода времени — возможно, всего несколько секунд. Таким образом, если сайт получает несколько запросов в секунду, большинство пользователей получают свою копию страницы из кэша. Это помогает время поиска для всех пользователей:

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

Вы можете кэшировать динамические файлы для WordPress, работающего в  стеке LAMP  или в стеке LEMP (описано в разделе 3 ). Есть несколько плагинов для кэширования, которые вы можете использовать с WordPress. Вот самые популярные плагины кэширования и методы кэширования, перечисленные от самых простых до самых мощных:

• Hyper-Cache  и  Quick-Cache  — эти два плагина создают один файл PHP для каждой страницы или публикации WordPress. Это поддерживает некоторые динамические функциональные возможности, в то же время обходя обработку ядра WordPress и соединение с базой данных, что ускоряет работу пользователя. Они не обходят всю обработку PHP, поэтому они не дают такой же прирост производительности, как следующие опции. Они также не требуют изменений в конфигурации NGINX.
• WP Super Cache  — самый популярный кеширующий плагин для WordPress. Он имеет множество настроек, которые представлены через простой в использовании интерфейс, показанный ниже. Мы показываем пример конфигурации NGINX в Совете 7 .
• W3 Total Cache  — это второй по популярности плагин кеша для WordPress. Он имеет даже больше настроек, чем WP Super Cache, что делает его мощным, но несколько сложным вариантом. Для примера конфигурации NGINX см.  Совет 6 .
• FastCGI  — CGI означает Common Gateway Interface, независимый от языка способ запрашивать и получать файлы в Интернете. FastCGI — это не плагин, а способ взаимодействия с кешем. FastCGI можно использовать как в Apache, так и в NGINX, где это наиболее популярный подход динамического кэширования; мы опишем, как настроить NGINX для его использования в  совете 5 .

Документация по этим плагинам и методикам объясняет, как настроить их в типичном стеке LAMP. Варианты конфигурации включают кеширование базы данных и объекта; минимизация для HTML, CSS и JavaScript файлов; и варианты интеграции для популярных CDN. Для настройки NGINX см. Советы, указанные в списке.

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

Совет 3. Перейти к NGINX

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

Кроме того, Apache загружает еще одну копию  mod_php модуля в память для каждого соединения, даже если он обслуживает только статические файлы (изображения, CSS, JavaScript и т. Д.). Это потребляет еще больше ресурсов для каждого соединения и дополнительно ограничивает емкость сервера.

Чтобы начать решать эти проблемы, перейдите от стека LAMP к стеку LEMP — замените Apache на (e) NGINX. NGINX обрабатывает многие тысячи одновременных подключений с фиксированной областью памяти, поэтому вам не нужно ни молотить, ни ограничивать одновременные подключения небольшим числом.

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

Вы можете использовать NGINX на всех веб-серверах в своем развертывании или же вы можете поместить сервер NGINX «напротив» Apache в качестве обратного прокси-сервера — сервер NGINX получает запросы клиентов, обслуживает статические файлы и отправляет запросы PHP в Apache, который обрабатывает их.

Для динамически генерируемых страниц — основного варианта использования WordPress — выберите инструмент кэширования, как описано в  разделе 2 . Ниже приведены советы по настройке NGINX для FastCGI, W3_Total_Cache и WP-Super-Cache. (Hyper-Cache и Quick-Cache не требуют изменений в конфигурации NGINX.)

Совет.  Кэши обычно сохраняются на диск, но вы можете использовать их  tmpfs для хранения кеша в памяти и повышения производительности.

Настроить NGINX для WordPress легко. Просто выполните следующие четыре шага, которые более подробно описаны в указанных советах:

1. Добавить поддержку постоянных ссылок — Добавить поддержку постоянных ссылок в NGINX. Это устраняет зависимость от  файла конфигурации .htaccess , который зависит от Apache. Смотрите  совет 4 .
2. Настройка для кэширования — выберите инструмент кэширования и реализуйте его. Доступны следующие варианты: кэш FastCGI, общий кэш W3, супер кэш WP, гипер кэш и быстрый кэш. Смотрите советы  5 ,  6 и  7 .
3. Внедрить меры безопасности — принять лучшие практики для безопасности WordPress на NGINX. Смотрите  совет 8 .
4. Настройка WordPress Multisite. Если вы используете WordPress Multisite, настройте NGINX для архитектуры подкаталогов, поддоменов или нескольких доменов. Смотрите  совет 9 .

Совет 4. Добавление поддержки постоянных ссылок в NGINX

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

Вы можете включить постоянные  ссылки  в WordPress с помощью NGINX, включив следующий  location блок в блок главного  сервера  . (Этот  location блок также включен в другие примеры кода ниже.)

try_files Директива говорит NGINX , чтобы проверить , существует ли запрашиваемый URL в файл (  $uri) или каталог ( $uri/) в корневом каталоге документов,  /var/www/example.com/htdocs . Если нет, NGINX выполняет перенаправление в  /index.php , передавая аргументы строки запроса в качестве параметров.

server {
    server_name example.com www.example.com;
    root /var/www/example.com/htdocs;
    index index.php;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

fastcgi_cache_path /var/run/nginx-cache levels=1:2       
                   keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    server_name example.com www.example.com;
    root /var/www/example.com/htdocs;
    index index.php;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    set $skip_cache 0;

    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
        set $skip_cache 1;
    }   

    if ($query_string != "") {
        set $skip_cache 1;
    }   

    # Don't cache uris containing the following segments
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php
                         |sitemap(_index)?.xml") {
        set $skip_cache 1;
    }   

    # Don't use the cache for logged in users or recent commenters
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass
        |wordpress_no_cache|wordpress_logged_in") {
        set $skip_cache 1;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }    

    location ~ \.php$ {
        try_files $uri /index.php;
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid  60m;
    }

    location ~ /purge(/.*) {
        fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
    }	

    location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png
                      |ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {

        access_log off;	
        log_not_found off;
        expires max;
    }

    location = /robots.txt {
        access_log off;
        log_not_found off;
    }

    location ~ /\. {
        deny  all; 
        access_log off;
        log_not_found off;
    }
}

server {
    server_name example.com www.example.com;

    root /var/www/example.com/htdocs;
    index index.php;
    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    include /path/to/wordpress/installation/nginx.conf;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
    }
}

server {
    server_name example.com www.example.com;
    root /var/www/example.com/htdocs;
    index index.php;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log debug;

    set $cache_uri $request_uri;

    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
        set $cache_uri 'null cache';
    }  
    if ($query_string != "") {
        set $cache_uri 'null cache';
    }   

    # Don't cache uris containing the following segments
    if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php
                          |wp-.*.php|/feed/|index.php|wp-comments-popup.php
                          |wp-links-opml.php|wp-locations.php |sitemap(_index)?.xml
                          |[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {

        set $cache_uri 'null cache';
    }  

    # Don't use the cache for logged-in users or recent commenters
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+
                         |wp-postpass|wordpress_logged_in") {
        set $cache_uri 'null cache';
    }

    # Use cached or actual file if it exists, otherwise pass request to WordPress
    location / {
        try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html 
                  $uri $uri/ /index.php;
    }    

    location = /favicon.ico {
        log_not_found off; 
        access_log off;
    }

    location = /robots.txt {
        log_not_found off
        access_log off;
    }

    location ~ .php$ {
        try_files $uri /index.php;
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        #fastcgi_pass 127.0.0.1:9000;
    }

    # Cache static files for as long as possible
    location ~*.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css
           |rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2
           |doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
        expires max;
        log_not_found off;
        access_log off;
    }
}

# Restrict access to WordPress Dashboard
location /wp-admin {
    deny  192.192.9.9;
    allow 192.192.1.0/24;
    allow 10.1.1.0/16;
    deny  all;
}

# Deny access to uploads which aren’t images, videos, music, etc.
location ~* ^/wp-content/uploads/.*.(html|htm|shtml|php|js|swf)$ {
    deny all;
}

# Deny public access to wp-config.php
location ~* wp-config.php {
    deny all;
}

# Deny access to wp-login.php
location = /wp-login.php {
    limit_req zone=one burst=1 nodelay;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    #fastcgi_pass 127.0.0.1:9000;
}

# Add support for subdirectory structure in WordPress Multisite
if (!-e $request_filename) {
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;
    rewrite ^(/[^/]+)?(/wp-.*) $2 last;                     
    rewrite ^(/[^/]+)?(/.*\.php) $2 last;                   
}

# Add support for subdomains
server_name example.com *.example.com;

# Avoid PHP readfile() for /blogs.dir/structure in the subdirectory path.
location ^~ /blogs.dir {
    internal;
    alias /var/www/example.com/htdocs/wp-content/blogs.dir;
    access_log off;
    log_not_found off;
    expires max;
}

============================================================

# Avoid php readfile() for /files/structure in the subdirectory path
location ~ ^(/[^/]+/)?files/(?.+) {
    try_files /wp-content/blogs.dir/$blogid/files/$rt_file /wp-includes/ms-files.php?file=$rt_file;
    access_log off;
    log_not_found off;
    expires max;
}

============================================================

# WPMU files structure for the subdomain path
location ~ ^/files/(.*)$ {
    try_files /wp-includes/ms-files.php?file=$1 =404;
    access_log off;
    log_not_found off;
    expires max;
}

============================================================

# Map blog ID to specific directory
map $http_host $blogid {
    default           0;
    example.com       1;
    site1.example.com 2;
    site1.com       2;
}