Как кэшировать контент в NGINX

Учебники

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

Читайте также: 10 лучших инструментов кэширования с открытым исходным кодом для Linux

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

При настройке в качестве кэша NGINX будет:

  • кэшировать статический и динамический контент.
  • улучшать производительность динамического контента с помощью микрокэширования.
  • подавать устаревший контент, одновременно перепроверяя его в фоновом режиме для лучшей производительности.
  • переопределять или устанавливать заголовки Cache-Control и многое другое.

В этой статье вы узнаете, как настроить NGINX в качестве Кэширования контента в Linux, чтобы ваши веб-серверы работали максимально эффективно.

Предварительные требования:

У вас должен быть установлен NGINX на вашем сервере Linux, если нет, следуйте этим руководствам по установке Nginx:

Кэширование статического контента на 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;
Enable FastCGI Cache in NGINX

Директива fastcgi_cache_path определяет количество параметров, которые включают:

  • /var/cache/nginx – путь к локальному дисковому каталогу для кэша.
  • levels – определяет уровни иерархии кэша, устанавливает двухуровневую иерархию каталогов внутри /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;
Define Caching Zone and Time

Если указано только время кэширования, как в нашем случае, кэшируются только ответы 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{}, либо server{}, либо location{}.

fastcgi_cache_min_uses  3
Set Minimum Cache Usage

Для включения повторной проверки просроченных элементов кэша с использованием условных запросов с заголовками «If-Modified-Since» и «If-None-Match», добавьте директиву fastcgi_cache_revalidate в контекст http{}, server{} или location{}.

fastcgi_cache_revalidate on;
Set Cache Re-validation

Вы также можете настроить NGINX на доставку кэшированного контента, когда исходный сервер или сервер FCGI недоступен, используя директиву proxy_cache_use_stale в директиве location.

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

proxy_cache_use_stale error timeout http_500;
Enable Serving of Stale Data

Еще одна полезная директива для настройки производительности кэширования FCGI – это fastcgi_cache_background_update, которая работает с директивой proxy_cache_use_stale. Когда установлено значение on, это указывает NGINX отдавать устаревший контент, когда клиенты запрашивают файл, который истек или находится в процессе обновления с сервера вверхнего уровня.

fastcgi_cache_background_update on;
Enable Cache Background Update

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

fastcgi_cache_lock on;
Enable Cache Lock

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

# nginx -t
# systemctl restart nginx
Check and Start Nginx Service

Затем проверьте, работает ли кэш правильно, попробуйте получить доступ к вашему веб-приложению или сайту, используя следующую команду curl (первый раз должен показать MISS, но последующие запросы должны показать HIT, как показано на скриншоте).

# curl -I http://testapp.tecmint.com
Test FastCGI Cache

Вот еще один скриншот, показывающий, что NGINX обслуживает устаревшие данные.

Test Nginx Serving Stale Data

Добавление исключений для обхода кэша

Можно установить условия, при которых 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 / {
	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.

Source:
https://www.tecmint.com/cache-content-with-nginx/