Объём кэша растёт по числу ключей, а не по трафику

Сколько места нужно кэшу страниц? Интуиция подсказывает: зависит от посещаемости. На деле объём определяется не трафиком, а числом разных ключей — вариантов одной и той же страницы.

Это пятая часть цикла «Кэш страниц без MISS».

Откуда берутся варианты

Каждая комбинация того, что входит в ключ кэша, — отдельный файл:

страницы × устройство (мобильный/десктоп) × язык × варианты адреса (?utm…)

Сайт на 250 страниц с двумя версиями под устройства и двумя языками — это уже тысяча файлов, ещё до рекламных меток.

Как кэш вырос в десять раз за ночь

На каталоге с двумя языками вечером в кэше было 197 копий на 28 МБ. За ночь в ключ добавилась языковая кука, и обход прогрел все варианты: утром — 2244 копии и 293 МБ, 59 % потолка в 500 МБ. Трафик за ночь не изменился — изменилось число ключей.

Для сравнения: крупный каталог с огромным трафиком целиком занимал 70–100 МБ — у него не было языков. Каталог среднего размера после перехода на кэш на неделю вышел на полку в 399 МБ — 80 % прежнего потолка.

Почему при кэше на неделю потолок надо поднимать

При короткой валидности копии постоянно перезаписываются и умирают, объём держится ниже. При долгой они живут неделю, и кэш растёт до полного числа ключей. Если потолок мал, nginx начинает чистить по давности обращения — и выкидывает ровно редкие страницы, ради которых держится прогрев.

Как посмотреть, что лежит в кэше

# сколько копий и какие пути — по строкам KEY: в файлах кэша
grep -rah '^KEY:' /var/cache/nginx/fastcgi | wc -l
grep -rah '^KEY:' /var/cache/nginx/fastcgi | sort | uniq -c | sort -rn | head
du -sh /var/cache/nginx/fastcgi

Этот способ не трогает сайт: запрос к странице её же и прогрел бы, а чтение файлов — нет.