Мікрокеш — це звичний 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 і перезібрати ключ з урахуванням усіх змінних, від яких залежить зміст відповіді.