Короткая валидность кэша не бесплатна: сколько стоит STALE

Классическая схема кэша: валидность 30 минут плюс «отдавай устаревшее, обновляй фоном». Кажется идеальной: посетитель всегда получает страницу мгновенно, а данные никогда не старше получаса. Мы так и жили, пока не посмотрели, сколько это стоит.

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

Каждое обращение к старой странице — полный рендер

При background_update любой запрос к копии старше 30 минут запускает полную сборку страницы в фоне. Посетитель этого не видит — поэтому проблема и незаметна. Но процессор платит за каждый такой запрос, нужен он или нет.

Замер на тестовой копии каталога, где не было ни одного посетителя: 1,3–1,7 ядра процессора круглосуточно и 36 запросов в секунду к базе. Нагружал не трафик, а сам кэш: обходчик прогрева честно обходил 178 страниц в час, и каждая уже успевала «устареть». При этом сам обходчик докладывал «холодных страниц: 0» — он перегревал то, что и так было тёплым.

Окно обновления видно посетителю

Второй сюрприз — короткая валидность заметна и людям. Замер на рабочем сайте, 12 страниц подряд, по два запроса к каждой:

Запрос	Статус	Время
первый к устаревшей странице	STALE	0,021–0,031 с
второй к той же странице, пока идёт обновление	HIT	0,10–0,60 с, однажды 1,5 с

Пока страница пересобирается, следующий посетитель попадает в окно обновления и ждёт. У каждой страницы такое окно открывается раз в 30 минут.

Сколько стоила эта нагрузка

Когда на том же каталоге перешли на валидность в неделю (о модели — следующая часть), процессор контейнера PHP упал с 29,9–49,0 % до 0,0–4,4 % при том же объёме прогрева.

Контрольный пример: где экономии не было

На другом сайте валидность была сутки, а не полчаса. Процессор там и так стоял на 0,00–0,01 %. Переход на неделю дал единообразие настроек и убрал суточное окно обновления, но процессора не сэкономил — экономить было нечего.