Уявіть каталог із 50 000 товарів: кожен PHP-запит генерує сторінку за 300–800 мс. При 50 паралельних відвідувачах сервер упирається в CPU та пам'ять, а час відгуку зростає до 3–5 секунд. Varnish — reverse-proxy кеш на рівні ядра Linux, який зберігає копії відповідей в ОЗУ й віддає їх за 1–5 мс без участі PHP. Ми налаштовуємо Varnish для Бітрікс з урахуванням усіх особливостей: сесії, кошик, авторизація, Composite. Наш досвід — понад 7 років роботи з Бітрікс, десятки проєктів з кешування. Один із клієнтів скоротив витрати на серверні потужності на $1.4k–1.9k/рік після впровадження Varnish.
Як Varnish вирішує проблему продуктивності Бітрікс?
Для анонімних відвідувачів Varnish перетворює динамічний PHP-сайт на статичний, знижуючи час завантаження з секунд до мілісекунд. Однак Бітрікс призначає сесійну куку PHPSESSID навіть анонімам із порожнім кошиком. Стандартна політика Varnish — не кешувати запити з Set-Cookie — вимикає кеш для всіх. Наша конфігурація VCL акуратно чистить службові куки (аналітика, реклама) і дозволяє кешування, якщо критичних кук не залишилося. Varnish швидше за Nginx FastCGI Cache у 5 разів при віддачі статики: при навантаженні 1000 RPS Varnish видає 99% HIT, тоді як FastCGI Cache — близько 70%.
Чому Varnish конфліктує з Бітрікс і як ми це виправляємо?
Основні точки конфлікту: куки авторизації BITRIX_SM_*, куки кошика BX_BASKET_ADD, адміністративна панель ^/bitrix/, POST-запити та HTTPS. Для HTTPS додаємо додатковий шар: клієнт -> Nginx (SSL termination) -> Varnish -> Nginx. У VCL забороняємо кешування для /bitrix/, POST-запитів та за наявності BITRIX_SM_UIDH. Куки аналітики (_ga, _gid, _ym_uid) видаляємо — вони не впливають на контент. Якщо після очищення кук не залишилося, знімаємо заголовок Cookie і кешуємо. Для інвалідації кешу при публікації товару використовуємо обробник OnAfterIBlockElementUpdate, що надсилає PURGE-запит із тегом. VCL дозволяє PURGE тільки з 127.0.0.1.
Приклад VCL-фрагмента для очищення кук:
sub vcl_recv { # Видаляємо службові куки if (req.http.Cookie) { set req.http.Cookie = regsuball(req.http.Cookie, "(^|; )(_ga|_gid|_ym_uid|_ym_d|_ym_isad)=[^;]+", ""); if (req.http.Cookie ~ "^;$") { unset req.http.Cookie; } } } Порівняння Varnish та Nginx FastCGI Cache
| Параметр | Varnish | Nginx FastCGI Cache |
|---|---|---|
| Швидкість віддачі | <1 мс (RAM) | <5 мс (RAM/диск) |
| Гнучкість VCL | Максимальна (умови, заголовки) | Середня (прості правила) |
| Інвалідація по тегах | Вбудована (PURGE) | Через сторонні модулі |
| Grace + Stale | Є (grace mode) | Є (stale-while-revalidate) |
| SSL termination | Немає (потрібен upstream) | Є (вбудований) |
| Навантаження на бекенд | Мінімальна | Трохи вища (передача заголовків) |
Varnish виграє за рахунок VCL-логіки та тегованої інвалідації, ідеально для складних каталогів Бітрікс. Економія на хостингу після впровадження становить у середньому $180–260/міс.
Як налаштувати інвалідацію кешу Varnish?
При оновленні товару через адміністративний інтерфейс Бітрікс обробник OnAfterIBlockElementUpdate у init.php надсилає HTTP-запит PURGE на Varnish. У VCL ми дозволяємо PURGE тільки з 127.0.0.1 і додатково перевіряємо заголовок X-Purge-Token. Для тегованої інвалідації використовуємо заголовок X-Cache-Tags: Varnish знімає кеш по тегу (наприклад, iblock_5). Це дозволяє точково скидати кеш лише для змінених розділів, не зачіпаючи весь сайт.
Процес налаштування Varnish для Бітрікс
| Етап | Дія | Тривалість |
|---|---|---|
| 1. Аналітика | Вивчаємо структуру сайту, типи сторінок, обсяг кешу, поточну швидкодію | 1-2 години |
| 2. Проектування VCL | Пишемо правила для статики, HTML, винятків (адмінка, кошик, особистий кабінет) | 2-4 години |
| 3. SSL termination | Налаштовуємо Nginx перед Varnish або HAProxy з сертифікатами | 1 година |
| 4. Реалізація | Розгортаємо Varnish, тестуємо на копії сайту | 2-4 години |
| 5. Інвалідація | Додаємо обробники подій у init.php, тегуємо сторінки |
2-3 години |
| 6. Інтеграція з Composite | При потребі вимикаємо кеш Varnish для HTML або налаштовуємо винятки | 1-2 години |
| 7. Моніторинг | Вмикаємо логування X-Cache (HIT/MISS), налаштовуємо сповіщення при падінні |
1 година |
| 8. Навантажувальне тестування | Вимірюємо RPS, час відповіді, відсоток HIT | 1-2 години |
Терміни та вартість
Налаштування Varnish під Бітрікс займає від 4 до 16 годин залежно від складності проєкту (наявність Composite, кількість серверів, нетривіальні бізнес-процеси). Вартість розраховується індивідуально — оцінюємо обсяг робіт на безкоштовній консультації. Залиште заявку на консультацію інженера з продуктивності Бітрікс.
Корисні посилання
Замовте налаштування Varnish — ваш сайт стане швидшим у 5-10 разів без зміни коду.