Memcached или Redis для Битрикс: где хранить кеш сайта

Кеш Битрикс - это первое, что я проверяю, когда клиент жалуется на тормозящий каталог или медленную админку. Вопрос обычно звучит так: держать кеш в файлах, поставить memcached или redis для битрикс - и ответ каждый раз разный, в зависимости от нагрузки, числа серверов и бюджета на инфраструктуру. Настраивал все три варианта на проектах разного масштаба, от лендинга на пару тысяч визитов в месяц до интернет-магазина с несколькими десятками тысяч заказов в год, и ниже разложу, что выбрать в конкретной ситуации, с конфигами и цифрами из практики.

Как Битрикс кеширует данные и когда хватает файлового кеша

В коробке у Битрикса несколько независимых слоёв кеша: управляемый кеш с результатами выборок из базы, HTML-кеш компонентов, composite-кеш, который отдаёт готовую страницу анонимным посетителям, и автокеширование агентов. По умолчанию всё это складывается файлами в /bitrix/cache и /bitrix/managed_cache/. На одном сервере с SSD такая схема работает быстро, потому что операционная система сама держит горячие файлы в page cache и диск почти не трогает.

Для сайта-визитки, блога или магазина до 300-500 товаров на одном сервере с посещаемостью до 2000-3000 визитов в сутки файлового кеша достаточно с запасом. Переход на memcached или redis для битрикс тут не даст ощутимого прироста скорости, зато добавит лишнюю точку отказа и сервис, который надо администрировать и мониторить.

Проблемы начинаются с ростом проекта. Каталог на 10-15 тысяч товаров с активными фильтрами по highload-инфоблокам генерирует тысячи мелких файлов кеша, и файловая система упирается в лимит inode и в скорость записи мелкими блоками. Если сайт работает на нескольких веб-серверах за балансировщиком и кеш лежит на общем NFS-диске, добавляются блокировки на запись между нодами - каждое обновление на одном сервере видят все остальные, и запись начинает тормозить всю группу. Сигналы, что пора менять хранилище кеша: несколько веб-серверов без общего быстрого диска, посещаемость от 8000-10000 визитов в сутки и TTFB на горячих страницах выше 300-400 мс даже при прогретом кеше.

Memcached для битрикс: настройка и ограничения

Memcached - это память под ключ-значение без сохранения на диск: перезапустили демон, кеш обнулился. Для Битрикса он хорош там, где несколько веб-серверов работают без общей файловой системы, а данные в кеше не критичны к потере, потому что их всегда можно перегенерировать из базы. Подключается через bitrix/.settings.php:

'cache' => array(
    'value' => array(
        'type' => 'memcache',
        'memcache' => array(
            'host' => 'localhost',
            'port' => '11211',
        ),
    ),
    'readonly' => true,
),

Из ограничений: лимит на размер одного значения по умолчанию 1 Мб, поднимается флагом ‑I при запуске демона, но раздувать его без веской причины не стоит. При рестарте сервиса кеш холодный, и первые минуты после деплоя нагрузка на MySQL заметно подскакивает. Вытеснение старых записей идёт по LRU без предупреждений, поэтому hit rate стоит смотреть регулярно через memcached-tool или stats: если промахи растут, значит выделенной памяти не хватает под текущий объём данных.

Когда memcached может подвести

На проекте с частыми деплоями и рестартами PHP-FPM я несколько раз ловил просадку на 30-40% по времени ответа в первые 2-3 минуты после каждого релиза именно из-за холодного кеша. Для сайтов с редким деплоем и стабильной посещаемостью это не критично, а для интернет-магазина в высокий сезон, когда релизы идут по несколько раз в день, лучше сразу смотреть на redis с персистентностью.

Redis для битрикс: персистентность и дополнительные возможности

Redis решает те же задачи, что memcached, но умеет сохранять данные на диск через RDB-снэпшоты и AOF-журнал, поддерживает более сложные структуры и pub/sub, которым пользуется модуль «Пуш и Rest API» и механизм инвалидации composite-кеша между нодами. На практике это значит, что после перезапуска сервиса или перезагрузки сервера кеш не обнуляется целиком - часть данных восстанавливается из снэпшота.

Пример из реального проекта: интернет-магазин на Битриксе с калькулятором доставки СДЭК на карточке товара. Раньше ответ калькулятора кешировался файлами на 15 минут, и в пиковые часы распродаж, когда карточки открывали одновременно 150-200 человек, часть запросов всё равно улетала во внешний API СДЭК из-за гонки за первым обращением после протухания кеша. Перенёс этот кусок в redis с тем же TTL, и за счёт единого хранилища для всех PHP-FPM воркеров количество обращений к внешнему API в пиковые минуты упало примерно в 4 раза.

Конфиг для .settings.php с расширением phpredis:

'cache' => array(
    'value' => array(
        'type' => 'redis',
        'redis' => array(
            'host' => '127.0.0.1',
            'port' => 6379,
        ),
    ),
    'readonly' => true,
),
'session' => array(
    'value' => array(
        'type' => 'redis',
        'handler' => 'redis',
        'redis' => array(
            'host' => '127.0.0.1',
            'port' => 6379,
        ),
    ),
    'readonly' => true,
),

Redis можно занять и под хранение сессий, вынеся их с диска, что дополнительно снимает нагрузку на файловую систему при большом числе одновременных пользователей.

Файлы, memcached и redis для битрикс: сравнение

Как перейти с файлов на redis без даунтайма

1. Установить redis-server и расширение phpredis, проверить через phpinfo(), что модуль подключился.
2. Прописать блок cache и при необходимости session в .settings.php, как в конфиге выше.
3. Очистить старый файловый кеш через админку: Настройки, Автокеширование, Очистить кеш, чтобы не осталось рассинхрона между старыми и новыми записями.
4. Прогреть кеш - пройтись краулером или руками по основным разделам каталога и посадочным страницам.
5. Задать лимит памяти и политику вытеснения в redis.conf, иначе при заполнении память может уйти в своп и просадить весь сервер.
6. Первые сутки следить за INFO memory и счётчиком evicted_keys: если вытеснений много, память выделена с запасом на будущее, а не под текущий объём.

maxmemory 512mb
maxmemory-policy allkeys-lru
appendonly yes

На одном из проектов такой переход снизил TTFB на горячих страницах каталога с 450 мс до 90-120 мс, а память redis под каталог на 8000 SKU стабилизировалась на уровне 300-400 Мб. Если разбираться с конфигами и мониторингом самому некогда, эту часть я беру на себя отдельной задачей - можно посмотреть подробнее про настройку и оптимизацию сервера под Битрикс, разовая консультация по конкретному проекту стоит от 3 000 ₽.

Типичные ошибки при переходе на memcached или redis

• Не выставлен лимит памяти в конфиге - сервис съедает всю доступную RAM, и сервер уходит в своп, что медленнее, чем работа вообще без кеша.
• Персонализированные блоки вроде корзины или данных авторизованного пользователя кешируются наравне с общими - в итоге один посетитель видит чужую корзину или чужое имя в шапке.
• Кеш и сессии свалены в одну базу redis без разделения - очистка кеша через FLUSHALL разом разлогинивает всех пользователей.
• Никто не смотрит hit rate и evictions после настройки - через полгода кеш давно работает неэффективно, а проблему находят только когда сайт снова начинает тормозить.

Частые вопросы

Что лучше для битрикс, memcached или redis?

Для нового проекта я обычно ставлю redis - он закрывает те же задачи, что memcached, плюс переживает рестарт сервиса и умеет хранить сессии с сохранением на диск. Memcached оставляю там, где redis уже занят под другие задачи с несовместимым конфигом, либо когда нужна максимально простая схема без персистентности.

Можно ли использовать redis одновременно для кеша и для сессий?

Можно, но лучше развести их по разным номерам базы redis или вообще по разным инстансам. Если держать всё в одной базе и чистить кеш через FLUSHALL, заодно снесутся и сессии - все пользователи разом разлогинятся.

Сколько памяти закладывать под redis на сайте битрикс?

Для каталога на 5000-8000 товаров с активным управляемым кешем обычно хватает 512 Мб - 1 Гб с запасом. Ориентир беру по факту: смотрю INFO memory после недели работы под реальной нагрузкой и добавляю 30-40% сверху, чтобы не упираться в eviction в пиковые часы.

Нужно ли отключать файловый кеш при переходе на redis?

Да, оставлять оба хранилища активными одновременно смысла нет - Битрикс работает с одним типом кеша, заданным в .settings.php. После переключения на redis старые файлы в /bitrix/cache можно смело удалить, предварительно прогрев кеш заново обходом основных страниц.