Nginx не работает кэширование статики

Кэширование ответа от backend с помощью NGINX

NGINX позволяет значительно ускорить процесс загрузки страницы, не обращаясь к бэкэнду, а выдавая готовый html из кэша. Для работы данной функции необходимо, чтобы веб-сервер был версии 0.7.44 и выше (проверить можно командой nginx -v).

Для FastCGI кэш задается с помощью опций fastcgi_cache_*. Для запросов к бэкэнду с помощью proxy_pass — proxy_cache_*.

Рекомендации и противопоказания

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

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

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

Настройка кэширования для proxy_pass

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

Включение кэширования

Открываем конфигурационный файл nginx:

В секцию http добавляем:

http <
.
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:64m inactive=2h max_size=2g;
.
>

* в данном примере мы задали глобальную настройку для кэширования:

• /var/cache/nginx — путь хранения кэша.
• levels — уровень вложенности каталогов. В данном примере мы задаем настройку, при которой в каталог с кэшем будет создан каталог, а в ней — еще один каталог.
• keys_zone — имя зоны в разделяемой памяти, где будет храниться кэш, а также ее размер.
• inactive — задает время, после которого кэш будет автоматически чиститься.
• max_size — максимальный размер данных под кэш. Когда место заканчивается, nginx сам удаляет устаревшие данные.

Создаем каталог для хранения кэша и задаем владельца:

chown nginx:nginx /var/cache/nginx

Настройка хостов

Чтобы определенный сайт или отдельная страница кешировала запрос, открываем конфигурационный файл с настройками виртуального домена или хоста, например:

. и добавим к proxy_pass кэширование — мы получим что-то на подобие:

location / <
if ($http_cookie

* «.+» ) <
set $cookie_cache_bypass 1;
>
proxy_cache_bypass $cookie_cache_bypass;
proxy_pass http://localhost:3000;
.
proxy_cache all;
proxy_cache_valid 404 502 503 5m;
proxy_cache_valid any 1h;
proxy_cache_use_stale error timeout invalid_header updating;
>

• set $cookie_cache_bypass 1 — задаем значения переменной $cookie_cache_bypass, если передаются куки. Необходимо для предотвращения отдачи устаревших данных.
• proxy_cache_bypass — не отдавать данные из кэша. В нашем случае, применяется при куках.
• proxy_pass — передает запросы на бэкэнд.
• proxy_cache — включаем кэширование.
• proxy_cache_valid — задает время кеширования. В нашем примере первый параметр задает кэширование страниц с кодами ответов 404, 502, 503 на 5 минут, второй — для всего остального на 1 час.
• proxy_cache_use_stale — указывает, в каких случаях можно отдать устаревший кэш.

Применение настроек

NGINX настроен. Проверим корректность настроек:

Если ошибок нет, применяем их:

systemctl restart nginx

Теперь заходим на сайт и смотрим в каталог с кэшем — в нем должны появиться каталоги и файлы:

Мы должны увидеть что-то на подобие:

drwx——. 3 nginx nginx 4096 Jan 25 16:09 0
drwx——. 5 nginx nginx 4096 Jan 25 16:09 2
drwx——. 5 nginx nginx 4096 Jan 25 16:15 3
drwx——. 3 nginx nginx 4096 Jan 25 16:09 4
drwx——. 4 nginx nginx 4096 Jan 26 05:08 5
drwx——. 3 nginx nginx 4096 Jan 25 16:09 6
drwx——. 3 nginx nginx 4096 Jan 26 04:18 7
drwx——. 3 nginx nginx 4096 Jan 25 16:10 8
drwx——. 5 nginx nginx 4096 Jan 25 16:15 a
drwx——. 3 nginx nginx 4096 Jan 25 16:09 b
drwx——. 5 nginx nginx 4096 Jan 26 04:19 e
drwx——. 3 nginx nginx 4096 Jan 25 19:55 f

Настройка кэширования для fastcgi_pass

Настройка fastcgi_cache аналогична proxy_cache и настройки можно сделать по подобию последнего, заменив proxy_ на fastcgi_. Мы разберем основные настройки без подробностей и комментариев.

Открываем конфиг nginx:

Добавляем в секцию http:

http <
.
fastcgi_cache_path /var/cache/fastcgi levels=1:2 keys_zone=fastcgi:64m inactive=2h max_size=2g;
.
>

* обратите внимание, что мы задали другой каталог и keys_zone.

Создаем каталог для кэша:

chown nginx:nginx /var/cache/fastcgi

location / <
if ($http_cookie

* «.+» ) <
set $cookie_cache_bypass 1;
>
fastcgi_cache_bypass $cookie_cache_bypass;
fastcgi_pass http://localhost:9000;
.
fastcgi_cache all;
fastcgi_cache_valid 404 502 503 5m;
fastcgi_cache_valid any 1h;
fastcgi_cache_use_stale error timeout invalid_header updating;
>

Проверяем настройки и применяем их:

systemctl restart nginx

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

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

Настройка выполняется для каждого виртуального хоста (секция server):

* ^.+\.(css|js)$ <
root /var/www/site
expires modified +1w;
>
location

* в данном примере мы задаем для файлов изображений (jpg, jpeg, gif, png) кэш до 31 декабря 2037 23:55:55 (max), для файлов css и js — 1 неделя с момента их модификации. Данные настройки мы задаем при помощи параметра expires, который, в свою очередь, задает заголовок cache-control. NGINX будет искать статические файлы в корневом каталоге /var/www/site.

После применяем настройки:

systemctl restart nginx

Отключение кэширования

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

location /proxy_nocache <
proxy_pass http://localhost:3000;
.
proxy_cache off;
>

location /fastcgi_nocache <
fastcgi_pass http://localhost:9000;
.
fastcgi_cache off;
>

* обратите внимание, что в данном примере мы отключаем кэширование как для запросов proxy_pass, так и fastcgi_pass.

При отключении кэширования для статики используем следующую конфигурацию:

* ^.+\.(jpg|jpeg|gif|png|css|js)$ <
root /var/www/site
expires epoch;
>
>

* expires epoch задаст заголовок сache-control с временем окончания кэша «1 января 1970 00:00:01».

Сброс кэша

Удалить кэш на стороне сервера nginx мы можем только для бэкэнда. Для статики нужно удалять кэш в самом браузере (например, в настройках или с помощью дополнений).

Для сброса кэша мы просто должны удалить содержимое каталога, который прописан в опции proxy_cache_path или fastcgi_cache_path — в нашем случае, это /var/cache/nginx и /var/cache/fastcgi соответственно.

а) для proxy_cache_path:

б) для fastcgi_cache_path:

Хранение кэша в оперативной памяти

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

Создаем обычный каталог, в который будем монтировать часть оперативной памяти:

. и дадим на него полные права:

chmod 777 /var/ramdisk

Монтируем часть оперативной памяти как обычный каталог:

mount -t tmpfs -o size=2G ramdisk /var/ramdisk

* в данном примере мы монтируем 2 Гб оперативной памяти как папку /var/ramdisk. Возможно, правильнее будет заранее убедиться в наличие свободной памяти командой free.

Для автоматического монтирования открываем на редактирование fstab:

ramdisk /var/ramdisk tmpfs nodev,nosuid,noexec,nodiratime,size=2G 0 0

Теперь, когда у нас есть каталог, данные которого хранятся в оперативной памяти, редактируем параметр proxy_cache_path или fastcgi_cache_path в NGINX:

proxy_cache_path /var/ramdisk levels=1:2 keys_zone=all:64m inactive=2h max_size=2g;

fastcgi_cache_path /var/ramdisk levels=1:2 keys_zone=fastcgi:64m inactive=2h max_size=2g;

Источник

Кешируем статику

Зачем заниматься этой ерундой! — говорят опытные пользователи — OS лучше вас знает как кешировать файлы! С кешем и префетчем в современных OS, точнее FS, проблем нет! Зачем плодить свои кеши и списки популярных материалов и все такое.

Но на самом деле история начиналось немного не так.

Но проблема тормозных бэкендов решена

Хабр, в очередной раз подсказал вариант решения — proxy_store и proxy_cache.
Но proxy_store использовать мне нельзя — сохранить негде, и с proxy_cache тоже проблемы.
Есть одно, большое такое, «но» — много лет назад я уже столкнулся с производительностью отдачи файлов и решил «пускай лучше nginx отдает конечные файлы за меня».
X-Accel-Redirect.
Проблема — nginx не может закешировать ответ из прокси если это не ответ, а команда. X-Accel-Redirect — не кешируется.
Выхода нет?

Исходную проблему зафиксировали

Теперь вернемся к началу топика.
Нам нужно отдать статику, на этот раз без вмешательства «умных» бэкэндов. Просто статику, но с glusterfs.
Директив для кеширования статики просто нет — не предусмотрены. Считается что OS сама не дура. Для статики есть только open_file_cache и настройка самой передачи файлов(sendfile/aio и компания).
Что делать?
Усложним задачу, и попробуем решить проблему исключительно средствами nginx, не внося никаких изменений в другие коды.

обычный конфиг

Пропатченый конфиг

Nginx делает proxy_pass сам на себя, кешируя результат. Возможно тут можно использовать fcgi, но так — нагляднее.

И никакой магии.
В случае с X-Accel-Redirect схема такая:

1. nginx получается запрос
2. пересылает себе, к сожалению запрос полный и реальный.
3. пересылает на прокси
4. получает ответ и отдает файл
5. ответ кешируется
6. .
7. PROFIT

Что это дает?

В смысле с X-Accel-Redirect с apache снимается вал запросов. На загруженной системе разница может составить 50 раз.
Но это понятно — php сам по себе, а через апач тем более, не самое реактивное решение.
Latenсy запроса меньше 40мс, лично у меня, не получался (общее время php+gluster).
В случае использования варианта с proxy_cache скорость отдачи приравнивается к скорости отдачи статики.

А что со статикой?

Отдача с gluster — 13мс — это нормальное время для системы без кеша.

Отдача из кеша — 1мс — это замечательное.

Важно учесть — сервера находятся в Германии, а клиенты в России.
Нормальные пинги до сайта 60-100мс.
Так что для клиента ускорение практически не заметно.

Но оно заметно для сервера.
1. Снизилась нагрузка на сервера, в том числе в попугаях Load average и soft-irq.
2. Снизился трафик между серверами (можно решить включив WORM(Write Once Read Many volume), но это уже не «прозрачно»).

3. Все стало работать чуть быстрее.

В итоге работы которые на 10% снизили скорость реакции на клиенте, получились в результате 10-ти кратного ускорения отдачи статики. Что снизило общую нагрузку на сервера примерно раз в 20.
Обратное утверждение, к сожалению, тоже будет верно — сколько не старайся, клиент может и не заметить.

PS: Многие знакомые сисадмины даже не допускали мысли о возможности работы такой схемы. Не позволяет кешировать/проксировать — значит нельзя.

Хорошие программисты не всегда хорошие сисадмины, а сисадмины, обычно, вообще не программисты.
Настоящие герои всегда идут в обход, в брод, и на велосипедах.

PPS: я, кстати, не сисадмин. И, быть может, все сделал не правильно.

Источник

Nginx кэширование: настройка

В примере закэшированные данные будут складываться на сервере 123.123.123.123 в каталог /var/cache/nginx. Максимальный размер файлов в кэше — 128 Мб, если этого буфера будет не хватать самые редко запрашиваемые данные будут вытесняться

На кэширующем Nginx сервере с адресом 123.123.123.123:

http <
proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=all:128m;
>

Каталог /var/nginx/cache нужно создать

Настройка виртуального хоста

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

server_name example.com;
access_log /var/log/nginx/access.log;

proxy_pass http://124.124.124.124:80/;
proxy_set_header Host $host;
proxy_buffering on;
proxy_cache all;
proxy_cache_valid any 30m;
proxy_cache_valid 200 1d;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;

>

В конфигурационном файле указано, что кэшировать нужно все содержимое, TTL установлен в 30 минут.

Виртуальный хост активируется

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled

Затем требуется перечитать конфигурацию

На основном Nginx сервере с адресом 124.124.124.124:

Никаких изменений здесь вносить не требуется — можно при необходимости запустить веб-сервер на альтернативном порту.

server <
listen *:80;
server_name example.com;
proxy_read_timeout 200s;
access_log off;

root /var/www/sites/example.com/;

location / <
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Виртуальный хост также следует активировать стандартным образом.

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled

Конфигурация может быть любой: Nginx + PHP-FPM или Nginx + Apache2 как в примере.

Добавляем файл index.php для того чтобы проверить кэширование

Теперь можно обратиться к сайту через браузер, «Works!» будет говорить о том, что запросы успешно перенаправляются.

На кэширующем Nginx сервере с адресом 123.123.123.123:

Теперь можно проверить появилось ли что-либо в каталоге, выделенном под хранилище данных

total 20
drwxr-xr-x 5 www-data root 4096 июл 22 15:34 .
drwxr-xr-x 3 root root 4096 июл 22 14:58 ..
drwx—— 4 www-data www-data 4096 июл 22 15:41 2
drwx—— 3 www-data www-data 4096 июл 22 15:07 8
drwx—— 3 www-data www-data 4096 июл 22 15:34 c

Файлы присутствуют, что говорит об успешной настройке.

Nginx кэширование позволяет использовать несколько машин, они могут определяться через upstream. Обычно используется до 10 машин.

Источник