Микрокеш — это обычный fastcgi_cache или proxy_cache с временем жизни в одну-пять секунд вместо привычных минут. Для динамической страницы, которая должна выглядеть как актуальная, секунда кеша незаметна пользователю, но снимает основную часть повторных запросов во время всплеска трафика — например, когда на сайт одновременно приходят сотни читателей по одной ссылке.
Чем микрокеш отличается от обычного fastcgi_cache
Обычное кеширование страниц на минуты или часы, описанное в статье про proxy_cache и fastcgi_cache, подходит для контента, который меняется редко — карточка товара, статья блога. Для страниц с частыми обновлениями, где кеш на 10 минут показывает заведомо старые данные, такой подход не годится.
Микрокеш решает другую задачу: он не делает страницу статичной, а просто не даёт одному и тому же запросу долбить PHP-FPM десятки раз в секунду. Время жизни записи — 1 или 2 секунды — достаточно, чтобы погасить всплеск одновременных запросов, но слишком мало, чтобы заметно устареть для живого человека.
Настройка fastcgi_cache на 1–5 секунд
Зона кеша и ключ настраиваются так же, как для обычного fastcgi_cache, — разница только в значении fastcgi_cache_valid и в более аккуратной работе с куками сессии, потому что микрокеш чаще применяется к странице целиком, включая часть, которую обычно не кешируют.
Связку nginx с php-fpm, через которую проходит запрос перед попаданием в кеш, настраивают по статье про Nginx и PHP-FPM.
fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=microcache:10m max_size=512m inactive=10m;
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_cache microcache;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_valid 200 1s;
fastcgi_cache_use_stale updating;
fastcgi_cache_lock on;
fastcgi_cache_bypass $cookie_PHPSESSID;
fastcgi_no_cache $cookie_PHPSESSID;
}
Почему секунда кеша даёт эффект, а не только минута
Эффект проще всего показать рядом с другими значениями TTL.
| TTL кеша | Что получает пользователь | Нагрузка на PHP-FPM |
|---|---|---|
| 0 (без кеша) | всегда свежие данные | каждый запрос идёт на бэкенд |
| 1 секунда | данные актуальны почти всё время | десятки одинаковых запросов в секунду схлопываются в один |
| 10 минут | данные могут устареть на минуты | минимальная, но неприемлема для часто меняющегося контента |
Эффект схлопывания в средней строке работает только при включённом fastcgi_cache_lock — без него одновременные запросы к холодному кешу всё равно ушли бы на бэкенд все сразу.
Где микрокеш особенно заметен: WordPress под всплеском трафика
Для WordPress без полноценного плагина статического кеша микрокеш на уровне nginx — быстрый способ пережить всплеск посетителей после того, как ссылка попала в соцсети или новостной агрегатор, не трогая код темы и плагинов.
Общие приёмы ускорения WordPress — кеш страниц, оптимизация изображений, CDN — разобраны в статье про ускорение WordPress. Микрокеш дополняет эти приёмы на случай, когда весь прогретый кеш страниц всё равно устаревает быстрее, чем нужно для пиковой нагрузки.
Чек-лист перед включением микрокеша
Короткое время жизни кеша не избавляет от типичных ошибок кеширования — наоборот, они проявляются быстрее, потому что кеш обновляется постоянно.
- Страницы для авторизованных пользователей исключены через fastcgi_cache_bypass и fastcgi_no_cache по куке сессии.
- fastcgi_cache_lock включён, иначе при реальном всплеске сотни запросов всё равно дойдут до бэкенда в первую секунду.
- Значение fastcgi_cache_valid подобрано отдельно для кодов ошибок, чтобы не кешировать случайный 500 на секунду дольше, чем нужно.
- Заголовок X-Cache-Status добавлен в ответ, чтобы быстро проверить через curl, что микрокеш действительно работает.
- Формы с CSRF-токеном и страницы оплаты не попадают под общее правило кеширования.
Частые вопросы
Не слишком ли мала секунда кеша, чтобы заметно снизить нагрузку?
При всплеске трафика запросы на одну и ту же страницу обычно идут не раз в секунду, а десятками или сотнями в ту же секунду — именно эту пачку микрокеш схлопывает в один запрос к PHP-FPM. Для равномерного трафика без всплесков эффект куда меньше.
Можно ли включить микрокеш только на время всплеска, а не постоянно?
Технически можно менять fastcgi_cache_valid на лету через reload конфигурации, но проще держать микрокеш включённым постоянно: при обычной нагрузке секунда задержки актуальности незаметна, а в момент всплеска защита уже на месте без ручного вмешательства.
Что делать, если после включения микрокеша пользователи видят чужие данные?
Это обычно значит, что в ключ кеша fastcgi_cache_key не попали параметры, которые делают ответ индивидуальным, — например, язык интерфейса или идентификатор из куки. Нужно немедленно отключить кеш для этой location и пересобрать ключ с учётом всех переменных, от которых зависит содержимое ответа.