Налаштування кешування статики за допомогою nginx у Debian - Debian Help
Недолік схеми в тому, що при додаванні зображень у пости доводилося вручну коригувати шлях із згенерованого автоматично на точний шлях до файлу.
Коли описана вище ситуація втомила остаточно, було вирішено змінити метод видачі статики на кешування. Практично nginx продовжує видавати статику, але вже прозоро. Тобто при зверненні до файлу зі списку розширень він потрапляє в кеш nginx і при повторному запиті видається вже з кешу безпосередньо без звернення до бекенду. Спробуємо описати як налаштувати кешування в nginx з урахуванням зазначеного завдання.
Використовувалися ОС Debian 7.0, nginx 1.2.1. Попередньо слід оновити Debian.
Взагалі кажучи, всі директиви вказані на офіційному сайті nginx, але важко для розуміння.
Оскільки в основному конфізі/etc/nginx/nginx.conf маємо рядокinclude /etc/nginx/conf.d/*.conf, то створюємо окремий файл/etc /nginx/conf.d/cache.conf з базовими налаштуваннями кешу:
Розберемо поелементно перший рядок, що починається зproxy_cache_path. Таких рядків може бути кілька, отже може бути кілька кешів зі своїми параметрами та іменами. Отже:
/var/cache/nginx - шлях до директорії з кешем.
levels=1:2 - рівні директорій із кешем. Рівні вкладеності задаються через двокрапку, цифрами задається довжина імені директорії. 1:2 говорить про те, що в директорії з кешем будуть створені директорії довжиною в одну шістнадцяткову цифру (від 0 до f) у кожній з яких будуть створені директорії з іменами, що складаються з двох шістнадцяткових цифр.
keys_zone=static_cache:100m - задається ім'я кеша (static_cache ) та його базовий розмір вмегабайт.
inactive=120m - час відсутності запитів до елемента кеша, після якого він видаляється з кешу. У хвилинах. Після цього, при запиті до того ж файлу, запит до бекенду і файл знову потрапить в кеш.
max_size=500M – максимальний розмір кешу в мегабайтах.
Другий рядок, як було з'ясовано експериментально, також необхідний для роботи кешу nginx:
proxy_cache_min_uses 1; - вказує після якої кількості запитів до файлу він потрапить у кеш.
Не забудьте створити директорію для кешу та задати для неї власника від імені якого працює nginx у Debian:
Потім у файлі опису сайту в директорії /etc/nginx/sites-available прописуємо приблизно таке:
В даному випадку ми також перенаправляємо запити на бекенд, але при цьому кешуємо їх на добу. Нас цікавлять такі параметри:
proxy_cache static_cache; - вказуємо який кеш використовувати.
proxy_cache_valid 1d; - дозволяє задати час кешування для різних кодів відповіді. За замовчуванням кешуються лише відповіді з кодами 200, 301 та 302.
proxy_cache_key "$request_method$http_if_modified_since$http_if_none_match$host$request_uri"; - цей рядок найцікавіший. Вона дозволяє налаштувати за якими ознаками вважати, що кешувати запити окремо. Наприклад, значення у файлі кешу nginx може виглядати так:
Видно, що в цьому випадку
$request_method = GET $host = droid.gesu.su $request_uri = /wp-content/plugins/addthis/css/output.css?ver=3.5.1
Тобто при використанні іншого способу запиту файл потрібно кешувати окремо. Те ж саме для одного імені для різних доменних імен або різних імен файлів для одного домену.
$http_if_modified_since та$http_if_none_match - дозволяють не видавати сторінки з відповіддю "304 Not Modified" або порожні сторінки. У нашому випадку це, швидше за все, не актуально, тому що ми видаємо статичний контент, який рідко змінюється.
Ряд змінних, які можна використовувати в рядкуproxy_cache_key, можна знайти у wiki nginx.
Ось, власне і все, для нашого випадку більшого не потрібне. Система кешування досить гнучка і дозволяє кешувати результати конкретних сторінок, що відображаються за конкретними запитами, що дозволяє додатково зняти навантаження з бекендів.
UPD. Якщо файли в кеші не створюються і в лозі є рядок:
То спробуйте збільшити значення буферів у блоці http: