Настройка кэширования FastCGI в Nginx
Nginx включает в себя модуль FastCGI, который позволяет использовать директивы для кэширования динамического контента в интерфейсе PHP. FastCGI устраняет необходимость искать дополнительные решения для кэширования страниц (например, обратные прокси или специальные плагины приложений). Контент также может быть исключен из кэширования на основе метода запроса, URL, cookies или любой другой переменной сервера.
Активация кэширования FastCGI
Чтобы следовать данному руководству, нужно заранее установить и настроить Nginx+PHP. Также нужно отредактировать конфигурационный файл виртуального хоста:
Внесите следующие строки в начало файла вне директивы server :
fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=MYAPP:100m inactive=60m;
fastcgi_cache_key «$scheme$request_method$host$request_uri»;
Директива fastcgi_cache_path задает путь к кэшу (/etc/nginx/cache), указывает его размер (100m), имя зоны памяти (MYAPP), уровни подкаталогов и таймер inactive.
Кэш можно размещать в любой удобной точке жесткого диска. Максимальный размер кеша не должен превышать RAM сервера+размер swap-файла; в противном случае будет выведена ошибка Cannot allocate memory. Если кэш не был использован в течение конкретного периода времени, указанного с помощью опции “inactive” (в данном случае это 60 минут), то Nginx удаляет его.
Директива fastcgi_cache_key указывает способ хеширования имен файлов. Согласно данным настройкам, Nginx будет шифровать файлы с помощью MD5.
Теперь можно перейти к директиве location, которая передает PHP-запросы модулю php5-fpm. В location ~ .php$ < >внесите следующие строки:
fastcgi_cache MYAPP;
fastcgi_cache_valid 200 60m;
Директива fastcgi_cache ссылается на зону памяти, которая уже была указана в директиве fastcgi_cache_path.
По умолчанию Nginx хранит кешированные объекты в течение времени, указанного с помощью одного из этих заголовков:
X-Accel-Expires
Expires
Cache-Control.
Директива fastcgi_cache_valid указывает срок хранения кэша по умолчанию, если ни одного из этих заголовков нет. Согласно установленному значению кэшируются только ответы с кодом состояния 200 (конечно, можно указать и другие коды состояния).
Проверьте настройки FastCGI
Затем перезапустите Nginx, если с настройками все в порядке.
На данном этапе файл vhost должен иметь следующий вид:
fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=MYAPP:100m inactive=60m;
fastcgi_cache_key «$scheme$request_method$host$request_uri»;
server listen 80;
root /usr/share/nginx/html;
index index.php index.html index.htm;
server_name example.com;
location / try_files $uri $uri/ /index.html;
>
location ~ \.php$ try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_cache MYAPP;
fastcgi_cache_valid 200 60m;
>
>
Теперь нужно проверить, работает ли кеширование.
Проверка кэширования FastCGI
Создайте PHP-файл, который выводит метку времени UNIX.
Затем несколько раз запросите данный файл через curl или веб-браузер.
root@server:~# curl http://localhost/time.php;echo
1382986152
root@server:~# curl http://localhost/time.php;echo
1382986152
root@server:~# curl http://localhost/time.php;echo
1382986152
Если кеширование выполняется должным образом, временная отметка всех запросов будет совпадать (поскольку ответ был кеширован).
Чтобы найти кэш этого запроса, нужно выполнить обратную запись кэша
root@server:~# ls -lR /etc/nginx/cache/
/etc/nginx/cache/:
total 0
drwx—— 3 www-data www-data 60 Oct 28 18:53 e
/etc/nginx/cache/e:
total 0
drwx—— 2 www-data www-data 60 Oct 28 18:53 18
/etc/nginx/cache/e/18:
total 4
-rw——- 1 www-data www-data 117 Oct 28 18:53 b777c8adab3ec92cd43756226caf618e
Можно также добавить заголовок X-Cache, который укажет, что данный запрос был обработан из кеша (X-Cache HIT) или напрямую (X-Cache MISS).
Над директивой server < >внесите:
add_header X-Cache $upstream_cache_status;
Перезапустите сервис Nginx и выполните подробный запрос с помощью curl, чтобы увидеть новый заголовок.
root@server:~# curl -v http://localhost/time.php
* About to connect() to localhost port 80 (#0)
* Trying 127.0.0.1.
* connected
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /time.php HTTP/1.1
> User-Agent: curl/7.26.0
> Host: localhost
> Accept: */*
>
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Server: nginx
< Date: Tue, 29 Oct 2013 11:24:04 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Cache: HIT
* Connection #0 to host localhost left intact
1383045828* Closing connection #0
Исключения кэширования
Некоторый динамический контент (например, страницы запроса аутентификации) кешировать не нужно. Такой контент можно исключить из кеширования при помощи переменных request_uri, request_method и http_cookie.
Ниже приведен пример настроек, который можно использовать в контексте server< >.
#Cache everything by default
set $no_cache 0;
#Don’t cache POST requests
if ($request_method = POST)
set $no_cache 1;
>
#Don’t cache if the URL contains a query string
if ($query_string != «»)
set $no_cache 1;
>
#Don’t cache the following URLs
if ($request_uri ~* «/(administrator/|login.php)»)
set $no_cache 1;
>
#Don’t cache if there is a cookie called PHPSESSID
if ($http_cookie = «PHPSESSID»)
set $no_cache 1;
>
Чтобы применить переменную $no_cache в соответствующие директивы, поместите следующие строки в location ~ .php$
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
Директива fastcgi_cache_bypass игнорирует существующий кэш для запросов, связанных с установленными нами ранее условиями. Директива fastcgi_no_cache вообще не будет кэшировать такие запросы.
Очистка кэша
Соглашение об именах кэша основывается на переменных, которые были применены в директиве fastcgi_cache_key.
Согласно этим переменным, при запросе http://localhost/time.php будут выведены следующие значения:
После хеширования этой строки в MD5 получилось бы следующее:
Это сформирует имя файла кэша в соотношении с подкаталогами, указанными в levels=1:2. Таким образом, первый уровень каталога в этой строке MD5 будет обозначен последним символом строки (в данном случае это символ е). Второму уровню принадлежат следующие после первого уровня 2 символа (18). Таким образом, вся структура каталогов этой кэш-зоны будет выглядеть так:
Основываясь на этом формате кеширования, можно создать скрипт очистки кэша в любом удобном языке. В данном руководстве для того используется PHP. Создайте файл:
$cache_path = ‘/etc/nginx/cache/’;
$url = parse_url($_POST[‘url’]);
if(!$url)
echo ‘Invalid URL entered’;
die();
>
$scheme = $url[‘scheme’];
$host = $url[‘host’];
$requesturi = $url[‘path’];
$hash = md5($scheme.’GET’.$host.$requesturi);
var_dump(unlink($cache_path . substr($hash, -1) . ‘/’ . substr($hash,-3,2) . ‘/’ . $hash));
?>
Отправьте POST-запрос на этот файл с URL, который нужно очистить.
curl -d ‘url=http://www.example.com/time.php’ http://localhost/purge.php
Скрипт выдаст true или false в зависимости от того, был очищен кш или нет. Обязательно исключите этот скрипт из кэширования, а также не забудьте ограничить доступ к нему.
Использование Nginx FastCGI Cache
FastCGI Cache — это система кэширования данных реализованая на уровне HTTP-сервера Nginx.
Преимущество FastCGI Cache заключается в том, что Nginx вернёт закешированный ответ пользователю сразу, как только получит запрос, при этом слой приложения не будет вовсе обрабатывать поступивший HTTP-запрос, если он имеется в кэше Nginx.
Использование FastCGI Cache — отличный способ снизить нагрузку на вашу систему.
Если на вашем сайте есть страницы, которые изменяются редко или задержка обновления информации на некоторое время не критична, то FastCGI Cache именно то, что нужно.
Схема работы Nginx FastCGI Cache
Если на сервер Nginx пришёл HTTP-запрос и некоторое время назад ответ на такой же запрос был помещён в кэш, то Nginx не станет передавать данный запрос на выполнение PHP-FPM, в место этого Nginx вернёт результат из кэша.
Задача
Предположим у нас есть web-система управления полётом на луну, которая написана на PHP. Каждый пользователь должен ввести свой логин и пароль, чтобы войти в систему и оказаться на главной странице космического приложения.
Главная страница нашего ресурса, на которую попадают пользователи прошедшие этап аутентификации, очень популярная. Все пользователи ежедневно многократно просматривают эту страницу. На ней выводится большое количество всевозможных данных. Чтобы сгенерировать эту страницу требуется выполнить порядка тридцати SQL-запросов в различные базы данных.
Важно отметить, у пользователей данные, которые они видят на главной странице могут отличаться.
Нам известно, что информация, которая выводится на этой странице может обновляться с задержкой в один час. Данные не потеряют свою ценность даже есть они немного устареют.
Что из этого следует?
- У каждого пользователя, прошедшего аутентификацию должна быть своя версия кэша главной страницы.
- До ввода логина и пароля и после этого главная страница системы выглядит по-разному. Не прошедшие аутентификацию пользователи видят только форму для входа в систему.
- Мы можем хранить данные в кэше в течение 1 часа.
Решение
Изначально наш виртуальных хост сконфигурирован следующим образом:
Первое, что мы сделаем добавим директиву fastcgi_cache_path в в контексте http.
fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=fastcgicache:10m inactive=70m max_size=512m;Первый аргумент /tmp/nginx_cache определяет место на сервере, где будет сохранён кэш. Папка /tmp нам подходит, так как она очищается автоматически при перезапуске сервера. Важно отметить, что всё, что будет хранится в /tmp/nginx_cache так же будет находится в оперативной памяти.
Второй аргумент — это уровень подпапок. Мы указали levels=1:2. Это означает, что уровень вложенности будет равняться 2.Нас это устраивает, так как в одной папке у нас не будет большого количества файлов, а значит и замедление доступа к файлам нам не грозит.
Третий аргумент — имя зоны разделяемой памяти кэша. Запись keys_zone=fastcgicache:10m означает, что названием зоны является fastcgicache, а 10m — это размер зоны в мегабайтах. Зона размеров в 10 Мб может хранить данные для примерно 80 000 ключей. Конечно, название зоны может быть другим.
Четвёртый аргумент — inactive=70m, определяет интервал времени, после истечении которого данные автоматически удаляются, в случае, если они не используются. Другими словами, если к данным кэша не обращаются в течение времени, заданного параметром inactive, то данные удаляются, независимо от их свежести. По умолчанию inactive равен 10 минутам.
Пятый аргумент max_size=512m — устанавливает верхний предел размера кэша. По умолчанию используется всё дисковое пространство. При достижении лимита, Nginx удалит наименее востребованные данные.
Далее мы должны задать ключ для кэширования данных. Это можно сделать при помощи директивы fastcgi_cache_key. Данная директива может быть указана в контекстах http, server и location.
Укажим в контексте server директиву fastcgi_cache_key:
fastcgi_cache_key "$scheme$request_method$host$request_uri$cookie_codeAuth";Здесь мы указали несколько переменных:
— $request_method
— $request_uri
— $cookie_codeAuth
Давайте разберёмся с ними подробнее. Нам важно понимать, какие значения будут принимать эти переменные.
Рассмотрим пример, допустим залогиненный пользователь указал в браузере такой запрос:
После выполнения этого запроса Nginx присвоит следующие значения нашим переменным: