Как кэшировать контент в NGINX
NGINX — это консолидированный высокопроизводительный веб-сервер с открытым исходным кодом, который ускоряет доставку контента и приложений, повышает безопасность и улучшает масштабируемость. Одним из наиболее распространенных вариантов использования Nginx является Кэширование контента, которое является наиболее эффективным способом повышения производительности веб-сайта.
Читайте также: 10 лучших инструментов кэширования с открытым исходным кодом для Linux
Вы можете использовать NGINX для ускорения локальных исходных серверов, настроив его для кэширования ответов от вышестоящих серверов, а также для создания пограничных серверов для сетей доставки контента (CDN). NGINX поддерживает некоторые из крупнейших CDN.
При настройке в качестве кэша NGINX будет:
- кэшировать статический и динамический контент.
- улучшить производительность динамического контента с помощью микрокеширования.
- обслуживать устаревший контент при повторной проверке в фоновом режиме для повышения производительности.
- переопределить или установить заголовки Cache-Control и многое другое.
В этой статье вы узнаете, как настроить NGINX в качестве кэширования контента в Linux, чтобы ваши веб-серверы работали максимально эффективно.
Предпосылки:
На вашем Linux-сервере должен быть установлен NGINX. В противном случае следуйте этим инструкциям по установке Nginx:
- Как установить Nginx на CentOS 8
- Как установить Nginx на CentOS 7
Кэшируйте статический контент в Nginx
Статический контент — это контент веб-сайта, который остается неизменным (не меняется) на всех страницах. Примеры статического контента включают такие файлы, как изображения, видео, документы; CSS-файлы и файлы JavaScript.
Если на вашем веб-сайте используется много статического контента, вы можете оптимизировать его производительность, включив кэширование на стороне клиента, при котором браузер сохраняет копии статического контента для более быстрого доступа.
Следующий пример конфигурации подойдет: просто замените www.example.com URL-адресом имени вашего веб-сайта и внесите соответствующие изменения в другие пути.
server {
# substitute your web server's URL for www.example.com
server_name 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;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
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;
}
}
Кэшировать динамический контент на Nginx
NGINX использует постоянный дисковый кеш, расположенный где-то в локальной файловой системе. Итак, начните с создания каталога на локальном диске для хранения кэшированного контента.
# mkdir -p /var/cache/nginx
Затем установите соответствующее право собственности на каталог кэша. Он должен принадлежать пользователю NGINX (nginx) и группе (nginx) следующим образом.
chown nginx:nginx /var/cache/nginx
Теперь перейдите дальше, чтобы узнать, как включить динамический контент в Nginx, в разделе ниже.
Включение кэша FastCGI в NGINX
FastCGI (или FCGI) – это широко используемый протокол для взаимодействия интерактивных приложений, таких как PHP, с веб-серверами, такими как NGINX . . Это расширение CGI (Common Gateway Interface).
Основное преимущество FCGI заключается в том, что он управляет несколькими запросами CGI в одном процессе. Без этого веб-серверу придется открывать новый процесс (который нужно контролировать, обрабатывать запрос и закрывать) для каждого запроса клиента на услугу.
Для обработки сценариев PHP при развертывании стека LEMP NGINX использует FPM (FastCGI Process Manager) или PHP-FPM, популярная альтернативная реализация PHP FastCGI. После запуска процесса PHP-FPM NGINX настраивается на проксирование запросов к нему для обработки. Таким образом, NGINX также можно настроить для кэширования ответов от внутреннего сервера приложений PHP-FPM.
В NGINX кэш содержимого FastCGI объявляется с помощью директивы fastcgi_cache_path в http{} верхнего уровня. контексте в структуре конфигурации NGINX. Вы также можете добавить fastcgi_cache_key, который определяет ключ (идентификатор запроса) для кэширования.
Кроме того, чтобы прочитать состояние восходящего кэша, добавьте директиву add_header X-Cache-Status в контекст http{} — это полезно для целей отладки.
Предполагается, что файл конфигурации блока сервера вашего сайта расположен по адресу /etc/nginx/conf.d/testapp.conf или /etc/nginx/sites-available/testapp.conf ( под Ubuntu и ее производные), откройте файл редактирования и добавьте следующие строки вверху файла.
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;
Директива fastcgi_cache_path определяет количество параметров:
- /var/cache/nginx – путь к каталогу локального диска для кэша.
- уровни – определяет уровни иерархии кэша. Он устанавливает двухуровневую иерархию каталогов в /var/cache/nginx.
- keys_zone (name:size) – позволяет создать зону общей памяти, где хранятся все активные ключи и информация о данных (мета). Обратите внимание, что хранение ключей в памяти ускоряет процесс проверки, позволяя NGINX определить, является ли это MISS или HIT, без проверки статуса на диске.
- inactive – указывает период времени, по истечении которого кэшированные данные, к которым не был осуществлен доступ в течение указанного времени, удаляются из кэша независимо от их актуальности. Значение 60m в нашем примере конфигурации означает, что файлы, к которым нет доступа после 60, будут удалены из кэша.
- max_size – указывает максимальный размер кэша. Здесь вы можете использовать больше параметров (дополнительную информацию можно найти в документации NGINX).
Переменные в директиве fastcgi_cache_key описаны ниже.
NGINX использует их при вычислении ключа (идентификатора) запроса. Важно отметить, что для отправки кэшированного ответа клиенту запрос должен иметь тот же ключ, что и кэшированный ответ.
- $scheme – схема запроса, HTTP или HTTPS.
- $request_method – метод запроса, обычно «GET» или «POST».
- $host – это может быть имя хоста из строки запроса, имя хоста из поля заголовка запроса «Host» или имя сервера, соответствующее запросу, в порядке приоритета. .
- $request_uri – означает полный исходный URI запроса (с аргументами).
Кроме того, переменная $upstream_cache_status в директиве add_header X-Cache-Status рассчитывается для каждого запроса, на который отвечает NGINX, независимо от того, является ли он MISS. > (ответ не найден в кеше, получен от сервера приложений) или HIT (ответ отправлен из кеша) или любое другое поддерживаемое значение.
Затем в директиве location, которая передает PHP-запросы в PHP-FPM, используются директивы fastcgi_cache для активации кэша, который вы только что определили выше.
Также установите время кэширования для различных ответов с помощью директивы fastcgi_cache_valid, как показано.
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 60m;
Если указано только время кэширования, как в нашем случае, кэшируются только ответы 200, 301 и 302. Но вы также можете указать ответы явно или использовать любые (для любого кода ответа):
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200 301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid any 10m;
Точная настройка производительности кэширования FastCGI в Nginx
Чтобы установить минимальное количество раз, которое запрос с одним и тем же ключом должен быть выполнен перед кэшированием ответа, включите директиву fastcgi_cache_min_uses либо в http{}, либо в . контекст >сервера{} или location{}.
fastcgi_cache_min_uses 3
Чтобы включить повторную проверку элементов кэша с истекшим сроком действия с использованием условных запросов с полями заголовка «If-Modified-Since» и «If-None-Match», добавьте fastcgi_cache_revalidate в контексте http{} или server{} или location{}.
fastcgi_cache_revalidate on;
Вы также можете указать NGINX доставлять кэшированный контент, когда исходный сервер или сервер FCGI не работает, используя директиву proxy_cache_use_stale в директиве location.
Этот пример конфигурации означает, что когда NGINX получает ошибку, тайм-аут или любую из указанных ошибок от вышестоящего сервера и имеет устаревшую версию запрошенного файла в кэшированном содержимом, он доставляет устаревший файл.
proxy_cache_use_stale error timeout http_500;
Еще одна полезная директива для точной настройки производительности кэширования FCGI — это fastcgi_cache_background_update, которая работает в сочетании с директивой proxy_cache_use_stale. Если этот параметр включен, он предписывает NGINX обслуживать устаревший контент, когда клиенты запрашивают файл, срок действия которого истек или находится в процессе обновления, с вышестоящего сервера.
fastcgi_cache_background_update on;
fastcgi_cache_lock также полезен для точной настройки производительности кэша: если несколько клиентов запрашивают один и тот же контент, которого нет в кэше, NGINX перенаправит только первый запрос на вышестоящий сервер, кэширует ответ затем обслуживает другие клиентские запросы из кеша.
fastcgi_cache_lock on;
После внесения всех вышеуказанных изменений в файл конфигурации NGINX сохраните и закройте его. Затем проверьте структуру конфигурации на наличие синтаксических ошибок перед перезапуском службы NGINX.
nginx -t
systemctl restart nginx
Затем проверьте, правильно ли работает кеш, попробуйте получить доступ к вашему веб-приложению или сайту с помощью следующей команды curl (первый раз должен указывать MISS, но последующие запросы должны указывать HIT) , как показано на скриншоте).
curl -I http://testapp.linux-console.net
Вот еще один снимок экрана, показывающий, как NGINX передает устаревшие данные.
Добавление исключений для обхода кэша
Можно задать условия, при которых NGINX не должен отправлять кэшированные ответы клиентам, с помощью директивы fastcgi_cache_bypass. А чтобы указать NGINX вообще не кэшировать ответы от вышестоящего сервера, используйте fastcgi_no_cache.
Например, если вы хотите, чтобы запросы POST и URL-адреса со строкой запроса всегда передавались на PHP. Сначала объявите оператор if, чтобы установить условие следующим образом.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Затем активируйте указанное выше исключение в директиве location, которая передает запросы PHP на PHP-FPM, используя fastcgi_cache_bypass и fastcgi_no_cache директивы.
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
Существует множество других частей вашего сайта, для которых вы, возможно, не захотите включать кэширование контента. Ниже приведен пример конфигурации NGINX для повышения производительности сайта WordPress, представленный в блоге nginx.com.
Чтобы использовать его, внесите изменения (например, домен, пути, имена файлов и т. д.), чтобы отразить то, что существует в вашей среде.
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;
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;
}
}
Включение прокси-кеша в NGINX
NGINX также поддерживает кэширование ответов от других прокси-серверов (определяется директивой proxy_pass). В этом тестовом примере мы используем NGINX в качестве обратного прокси-сервера для веб-приложения Node.js, поэтому мы включим NGINX в качестве кэша для приложения Node.js. Все используемые здесь директивы конфигурации имеют то же значение, что и директивы FastCGI в предыдущем разделе, поэтому мы не будем объяснять их снова.
Чтобы включить кэширование ответов от прокси-сервера, включите директиву proxy_cache_path в контекст http{} верхнего уровня. Чтобы указать, как кэшируются запросы, вы также можете добавить директиву proxy_cache_key следующим образом.
proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m;
proxy_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
proxy_cache_min_uses 3;
Затем активируйте кеш в директиве location.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
Чтобы определить условия, при которых NGINX не отправляет кэшированный контент и вообще не кэширует ответ от вышестоящего сервера, включите proxy_cache_bypass и proxy_no_cache.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache $http_pragma $http_authorization;
Точная настройка производительности кэша прокси
Следующие директивы полезны для точной настройки производительности кэша прокси. Они также имеют то же значение, что и директивы FastCGI.
proxy_cache_min_uses 3;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout updating http_500;
proxy_cache_background_update on;
proxy_cache_lock on;
Дополнительную информацию и директивы конфигурации кэширования см. в документации по двум основным модулям ngx_http_fastcgi_module и ngx_http_proxy_module.
Дополнительные ресурсы: кэширование контента NGINX и советы по улучшению производительности WordPress.