Зауважте: коли ваш веб-сервер починає задихатися при пікових навантаженнях, а час відповіді (TTFB) перевищує 500 мс — це сигнал, що час впроваджувати HTTP-акселератор. Varnish Cache перехоплює запити до backend і віддає кешовані відповіді з оперативної пам'яті. В результаті затримка знижується до 1–5 мс, а сервер витримує десятки тисяч запитів на секунду. Ми — команда з 5-річним досвідом у налаштуванні Varnish, яка реалізувала понад 100 проектів для highload-сервісів. Правильне налаштування Varnish покращує Core Web Vitals (LCP, INP). Типовий hit rate при коректній VCL досягає 95–99%, а час відповіді скорочується в 100 разів порівняно з прямим зверненням до backend.
Проблеми, які вирішує Varnish
- Високе навантаження на backend. Без кешування кожен запит обробляється додатком — база даних, рендеринг, бізнес-логіка. Varnish знімає до 90% навантаження, обслуговуючи кешовані сторінки безпосередньо.
- Повільні динамічні сторінки. Навіть якщо сторінка генерується 200 мс, при 1000 паралельних запитах час очікування зростає. Varnish з фрагментарним кешуванням (ESI) дозволяє кешувати спільну частину, а персоналізовані блоки підвантажувати асинхронно. Це скорочує час генерації сторінки на 60–80%.
- Нестабільна робота при піках трафіку. Varnish виступає буфером: якщо backend тимчасово недоступний, віддається застаріла копія (grace mode). Це запобігає простоям і помилкам 503.
Як Varnish покращує Core Web Vitals?
Core Web Vitals — метрики, від яких залежить ранжування в Google. Varnish безпосередньо впливає на Largest Contentful Paint (LCP) та Interaction to Next Paint (INP). При кешуванні HTML-сторінок LCP падає з 2–3 секунд до 200–300 мс. INP покращується завдяки тому, що сервер швидше віддає контент, зменшуючи затримку для скриптів. На одному з проектів hit rate зріс з 40% до 98% після коригування VCL.
Grace mode: навіщо він потрібен?
Grace mode — це механізм, який дозволяє віддавати застарілий кеш, якщо backend не відповів вчасно. Як зазначено в документації Varnish: Grace mode дозволяє віддавати застарілий кеш, запобігаючи помилкам 503. Налаштування beresp.grace = 6h дає 6 годин на відновлення, протягом яких Varnish продовжує віддавати стару копію. Це критично для highload-проектів, де кожна секунда простою коштує грошей.
Коли Varnish не потрібен?
Varnish не ефективний для сайтів з повністю персоналізованим контентом (особистий кабінет, онлайн-банкінг), де кожен запит потребує унікальних даних. У таких випадках краще використовувати кешування на рівні додатку (Redis, Memcached) або CDN. Однак навіть для таких проектів Varnish може кешувати статику та спільні блоки.
Базова конфігурація VCL
# Debian/Ubuntu
apt install varnish
# /etc/varnish/default.vcl
vcl 4.1;
import std;
backend default {
.host = "127.0.0.1";
.port = "8080";
.first_byte_timeout = 60s;
.connect_timeout = 5s;
.between_bytes_timeout = 10s;
}
# Несколько бэкендов с балансировкой
import directors;
backend app1 { .host = "10.0.0.1"; .port = "8080"; }
backend app2 { .host = "10.0.0.2"; .port = "8080"; }
sub vcl_init {
new cluster = directors.round_robin();
cluster.add_backend(app1);
cluster.add_backend(app2);
}
sub vcl_recv {
set req.backend_hint = cluster.backend();
# Нормализация URL (удалить trailing slash кроме корня)
if (req.url ~ "^(/[^?]+)/$") {
set req.url = regsub(req.url, "/$", "");
}
# Не кэшировать admin-панель
if (req.url ~ "^/admin") {
return (pass);
}
# Не кэшировать авторизованных пользователей (если контент персонализирован)
if (req.http.Authorization || req.http.Cookie ~ "session_id|auth_token") {
return (pass);
}
# Удалить маркетинговые параметры из ключа кэша
set req.url = regsuball(req.url, "(\\?|&)(utm_source|utm_medium|utm_campaign|utm_content|fbclid|gclid)=[^&]+", "");
set req.url = regsub(req.url, "\\?&", "?");
set req.url = regsub(req.url, "\\?$", "");
# Нормализовать Accept-Encoding
if (req.http.Accept-Encoding) {
if (req.url ~ "\\.(gif|jpg|jpeg|png|webp|avif|ico|zip|gz|mp4)$") {
unset req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "br") {
set req.http.Accept-Encoding = "br";
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} else {
unset req.http.Accept-Encoding;
}
}
}
sub vcl_backend_response {
# Кэшировать 404 ненадолго
if (beresp.status == 404) {
set beresp.ttl = 30s;
return (deliver);
}
# Кэшировать только успешные ответы
if (beresp.status != 200 && beresp.status != 301 && beresp.status != 302) {
set beresp.uncacheable = true;
return (deliver);
}
# Если backend не прислал Cache-Control — установить по умолчанию
if (!beresp.http.Cache-Control) {
if (bereq.url ~ "\\.(css|js|woff2|png|jpg|svg)$") {
set beresp.ttl = 30d;
} else {
set beresp.ttl = 5m;
}
}
# Grace period: отдавать устаревший кэш при backend сбое
set beresp.grace = 6h;
# Сжатие
if (beresp.http.content-type ~ "text/(html|css|javascript|xml|plain)" ||
beresp.http.content-type ~ "application/(json|javascript)") {
set beresp.do_gzip = true;
}
# Не хранить Set-Cookie в кэше
unset beresp.http.Set-Cookie;
}
sub vcl_deliver {
# Debug заголовок (отключить в production)
if (obj.hits > 0) {
set resp.http.X-Cache = "HIT " + obj.hits;
} else {
set resp.http.X-Cache = "MISS";
}
# Скрыть внутренние заголовки от клиента
unset resp.http.X-Varnish;
unset resp.http.Via;
unset resp.http.X-Powered-By;
}
sub vcl_hit {
if (obj.ttl >= 0s) { return (deliver); }
# Grace: отдать устаревший объект
if (obj.ttl + obj.grace > 0s) { return (deliver); }
return (restart);
}
Інвалідація кешу: PURGE, BAN, ESI
acl purge_acl {
"127.0.0.1";
"10.0.0.0"/8;
}
sub vcl_recv {
if (req.method == "PURGE") {
if (!client.ip ~ purge_acl) {
return (synth(405, "Not allowed"));
}
return (purge);
}
if (req.method == "BAN") {
if (!client.ip ~ purge_acl) {
return (synth(405, "Not allowed"));
}
ban("req.http.host == " + req.http.host + " && req.url ~ " + req.url);
return (synth(200, "Ban added"));
}
}
Використання з додатку:
# Інвалідувати конкретний URL
curl -X PURGE http://localhost/page/about
# Інвалідувати за патерном (BAN)
curl -X BAN -H "Host: company.com" http://localhost/category/
ESI (Edge Side Includes)
sub vcl_backend_response {
if (beresp.http.Surrogate-Control ~ "ESI/1.0") {
set beresp.do_esi = true;
}
}
Процес налаштування, типові помилки та що входить в роботу
Процес налаштування
- Аудит додатку: аналіз URL, cookies, сесій, частота оновлення.
- Проектування VCL: правила кешування, TTL, grace, ESI.
- Тестування на staging: замір hit rate, навантаження на backend.
- Деплой: налаштування systemd, виділення пам'яті, моніторинг.
- Моніторинг та оптимізація: varnishstat, Prometheus, коригування VCL.
Чек-лист аудиту додатку перед налаштуванням Varnish
- Аналіз структури URL та параметрів
- Виявлення динамічних та статичних сторінок
- Перевірка використання cookies та сесій
- Визначення частоти оновлення контенту
- Виявлення вузьких місць у продуктивності backend
Типові помилки та рекомендації
| Помилка | Рішення |
|---|---|
| Ігнорування нормалізації URL | Додати нормалізацію trailing slash у vcl_recv |
| Кешування авторизованих сторінок | Перевіряти cookies та Authorization header, return(pass) для персоналізованого контенту |
| Занадто довгий TTL для динаміки | Встановити розумний TTL (1–5 хвилин) для сторінок з контентом, що часто змінюється |
| Тип контенту | TTL | Grace | ESI | Приклад URL |
|---|---|---|---|---|
| Статика (CSS, JS, картинки) | 30 днів | 12 год | Ні | /static/css/app.css |
| Сторінки каталогу | 5 хвилин | 6 год | Так (для фільтрів) | /catalog/phones/ |
| Персоналізовані сторінки | 0 (pass) | - | Ні | /account/ |
Що входить в роботу
- Аудит поточної архітектури та виявлення вузьких місць
- Проектування та написання VCL-конфігурації з урахуванням специфіки проекту
- Налаштування балансування та grace mode
- Реалізація інвалідації PURGE/BAN та ESI за потреби
- Тестування на staging та вимірювання продуктивності
- Деплой у production та налаштування моніторингу (Prometheus + Grafana)
- Документація та навчання команди
- Гарантійна підтримка після впровадження
Терміни та вартість
Базове налаштування Varnish з типовою VCL займає 1–2 робочих дні. Для проектів з нестандартною архітектурою, ESI або складними правилами інвалідації — 2–3 дні. Вартість розраховується індивідуально після аудиту.
Замовте налаштування Varnish та отримайте консультацію — ми допоможемо збільшити продуктивність вашого сайту. Зв'яжіться з нами, щоб обговорити ваш проект.
Для поглибленого вивчення VCL ми рекомендуємо документацію Varnish.