Ми стикалися з проектами, де кожен запит до сторінки перетворювався на десятки SQL-запитів. Гальмував навіть простий блог. Після впровадження багаторівневого кешування час відповіді впав з 2000 мс до 80 мс, а навантаження на базу знизилося на 95%. Клієнти суттєво знижують витрати на інфраструктуру після такої оптимізації. Розповідаємо, як побудувати таку систему.
Багаторівневе кешування — це послідовність шарів зберігання відповідей. Кожен шар обслуговує запит, не передаючи його далі. Чим ближче до користувача потрапляння в кеш, тим швидша відповідь. Правильна стратегія знижує навантаження на базу даних і сервер додатку, а також покращує Core Web Vitals.
Чому недостатньо одного рівня кешування?
Браузерний кеш економить трафік, але не допомагає при першому візиті. CDN прискорює доставку статики, але для динамічних сторінок потрібен швидший шар. Varnish — потужний reverse proxy, але не вміє зберігати складні структури даних. На відміну від Apache mod_cache, Varnish працює в 10 разів швидше завдяки оптимізованій VCL. Redis вирішує це завдання, але потребує оперативної пам'яті. Комбінація цих інструментів дає максимальний ефект: типовий сайт після налаштування отримує hit rate >80% на CDN та >70% на Varnish.
| Рівень | Типовий час відповіді | Цільовий hit rate |
|---|---|---|
| Browser cache | 0 ms | >60% для статики |
| CDN | 5-30 ms | >80% для публічних сторінок |
| Varnish | 1-5 ms | >70% для HTML |
| Redis | 1-5 ms | >85% для даних |
| Database | 5-100 ms | - |
Кешування бази даних (query cache) може додатково підвищити продуктивність, досягаючи hit rate >90% для повторюваних запитів.
Рекомендовані TTL для різних типів контенту
| Тип контенту | Browser Cache | CDN | Varnish | Redis |
|---|---|---|---|---|
| Статика (css, js, img) | 1 рік | 30 днів | не кешується | не кешується |
| HTML сторінки | 0 (s-maxage=300) | 5 хв | 5 хв | не кешується |
| JSON API | не кешується | 1 хв | 1 хв | 5 хв |
| Сесії користувачів | не кешується | не кешується | не кешується | 30 хв |
Ці TTL потрібно коригувати під частоту змін контенту. Для новинного порталу HTML краще кешувати на 2 хвилини, для корпоративного сайту — на годину. Ми завжди проводимо навантажувальне тестування, щоб переконатися, що hit rate відповідає цільовим значенням.
Як налаштувати браузерне кешування?
# nginx: заголовки для браузерного кешу location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } location ~* \.html$ { add_header Cache-Control "public, max-age=0, s-maxage=300"; add_header Vary "Accept-Encoding, Accept-Language"; } Директива immutable говорить браузеру не перевіряти актуальність файлу — він гарантовано не зміниться. Це дає миттєве завантаження при повторних візитах. Браузерний кеш у 100 разів швидший за запит до сервера.
Підключення CDN
# cloudflare page rules - pattern: "*.company.com/assets/*" settings: cache_level: cache_everything edge_cache_ttl: 2592000 # 30 днів browser_cache_ttl: 31536000 # 1 рік CDN знімає навантаження з origin і скорочує TTFB для географічно віддалених користувачів.
Varnish: тонке налаштування
Повний приклад конфігурації Varnish
vcl 4.1; backend default { .host = "app-server"; .port = "8080"; } sub vcl_recv { if (req.http.Authorization || req.http.Cookie ~ "session") { return (pass); } if (req.method != "GET" && req.method != "HEAD") { return (pass); } unset req.http.Cookie; return (hash); } sub vcl_backend_response { if (beresp.status == 200 || beresp.status == 301) { if (beresp.http.Content-Type ~ "text/html") { set beresp.ttl = 5m; } else if (beresp.http.Content-Type ~ "application/json") { set beresp.ttl = 1m; } unset beresp.http.Set-Cookie; } set beresp.grace = 1h; } sub vcl_deliver { if (obj.hits > 0) { set resp.http.X-Cache = "HIT"; } else { set resp.http.X-Cache = "MISS"; } } Згідно з документацією Varnish Cache, grace period дозволяє обслуговувати застарілий кеш, коли backend недоступний, що підвищує доступність. Hash key можна кастомізувати для розділення кешу за мовами або пристроями.
Вирішення проблеми інвалідації кешу
Без правильної інвалідації користувачі побачать застарілі дані. Ми проєктуємо єдину систему: при зміні даних надсилаються HTTP PURGE на Varnish, видаляються ключі Redis та очищаються теги CDN. Приклад на Python:
def on_product_updated(product_id): redis.delete(f"product:{product_id}") requests.request('PURGE', f"http://varnish:6081/products/{product_id}") # Cloudflare purge by tag requests.post(f"https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache", headers={"Authorization": f"Bearer {token}"}, json={"tags": [f"product-{product_id}"]}) Типова помилка — налаштування надто довгих TTL без механізму інвалідації. Ми рекомендуємо використовувати теги на CDN та PURGE на Varnish, щоб гарантувати свіжість даних. У деяких сценаріях ми застосовуємо Edge Functions для миттєвої інвалідації на межі мережі.
Моніторинг hit rate за рівнями
Використовуємо Prometheus метрики: varnish_main_cache_hit / (varnish_main_cache_hit + varnish_main_cache_miss), redis_keyspace_hits_total / (redis_keyspace_hits_total + redis_keyspace_misses_total). Цільові значення вказані в таблиці вище. Регулярний моніторинг дозволяє своєчасно коригувати TTL та виявляти проблеми з інвалідацією.
Що входить в роботу?
- Аудит поточної архітектури кешування — аналізуємо логи nginx, конфіги Varnish, параметри Redis та структуру CDN.
- Налаштування Browser Cache через nginx або .htaccess.
- Підключення CDN (Cloudflare, CloudFront) з правилами кешування.
- Встановлення та конфігурація Varnish (4.1+) з правилами grace та hash.
- Налаштування Redis (кластер, персистентність, eviction policy).
- Створення єдиної системи інвалідації з PURGE та API.
- Навантажувальне тестування та оптимізація TTL.
- Документація та навчання команди.
Терміни та вартість
Налаштування повного стеку — від 4 до 7 робочих днів. Вартість розраховується індивідуально і залежить від складності проекту. Наприклад, налаштування для інтернет-магазину з 10 000 товарів коштує близько $1000, а середня економія на серверних ресурсах після впровадження становить $500 на місяць. Клієнти зазвичай окуповують вкладення за 2–3 місяці за рахунок зниження витрат на сервери та підвищення конверсії.
Поширена помилка — неправильне налаштування TTL
Багато хто встановлює однакові TTL для всіх типів контенту. Це призводить або до надмірного кешування динамічних даних, або до надто частої інвалідації статики. Ми підбираємо TTL на основі частоти оновлення контенту: статика — на рік, HTML — 5 хвилин, JSON API — 1 хвилина. Після налаштування перевіряємо hit rate і коригуємо при необхідності.
Спеціалізуємося на оптимізації продуктивності сайтів понад 5 років, виконали більше 50 проектів. Замовте аудит поточного кешування — ми виявимо вузькі місця і запропонуємо оптимальну стратегію. Отримайте консультацію з налаштування багаторівневого кешування для вашого проекту.