Представьте каталог с 50 000 товаров: каждый PHP-запрос генерирует страницу за 300–800 мс. При 50 параллельных посетителях сервер упирается в CPU и память, а время отклика растёт до 3–5 секунд. Varnish — reverse-proxy кеш на уровне ядра Linux, который хранит копии ответов в ОЗУ и отдаёт их за 1–5 мс без участия PHP. Мы настраиваем Varnish для Битрикс с учётом всех особенностей: сессии, корзина, авторизация, Composite. Наш опыт — более 7 лет работы с Битрикс, десятки проектов по кешированию. Один из клиентов сократил расходы на серверные мощности на 150 000 руб/год после внедрения 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-логики и тегированной инвалидации, идеально для сложных каталогов Битрикс. Экономия на хостинге после внедрения составляет в среднем 20 000 руб/мес.
Как настроить инвалидацию кеша 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 раз без изменения кода.