Кэширование в компонентах

Кэширование — главный инструмент производительности компонентов в 1С-Битрикс. Правильно настроенный кэш убирает лишние запросы к базе и ускоряет отдачу страниц в разы, а неверный — приводит к устаревшим данным и трудноуловимым багам.

Какие виды кэша есть в компонентах

В компонентах используют несколько уровней кэширования, которые дополняют друг друга:

• Кэш компонента — сохраняет $arResult и результат работы шаблона;
• Тегированный кэш — привязывает кэш к сущностям и сбрасывает его при их изменении;
• Автокэширование — глобальный режим, когда кэш включается для всех компонентов автоматически;
• Композитный (HTML) кэш — отдаёт статическую часть страницы мгновенно.

startResultCache и endResultCache

Базовый механизм — обёртка вокруг выборки данных. В классе компонента это выглядит так:

if ($this->startResultCache()) {
  $this->arResult['ITEMS'] = $this->loadItems();
  $this->includeComponentTemplate();
}

Метод startResultCache() возвращает false, если валидный кэш найден — тогда весь блок пропускается и данные берутся из файла. Если внутри блока нужно прервать кэширование (например, ничего не найдено), вызывают $this->abortResultCache().

Из чего складывается ключ кэша

Битрикс формирует уникальный ключ кэша автоматически на основе входных данных. По умолчанию в него входят параметры компонента, шаблон и часть окружения. Дополнительные факторы задают через startResultCache():

$this->startResultCache(false, array($USER->GetGroups(), $arParams['CITY']));

Второй аргумент — additionalCacheID — добавляет в ключ группы пользователя и город. Это важно, когда вывод зависит от прав доступа или региона.

Тегированное кэширование

Кэш по времени (CACHE_TIME) сбрасывается по таймеру, что либо отдаёт устаревшие данные, либо часто пересчитывает их. Тегированный кэш решает это: он инвалидируется при изменении конкретной сущности.

$tagged = \Bitrix\Main\Application::getInstance()->getTaggedCache();
$tagged->registerTag('iblock_id_' . $iblockId);

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

Тегированный кэш решает классическую дилемму: с одной стороны, хочется ставить большое время жизни, чтобы реже нагружать базу; с другой — контент-менеджеры ждут, что правки появятся сразу. С тегами можно смело выставлять CACHE_TIME в 36000 секунд и больше: кэш всё равно сбросится в момент изменения данных, а не по таймеру. Регистрировать теги вручную нужно только для нестандартных источников — например, при выборке из highload-блоков или внешних таблиц, о которых ядро само не знает.

Сравнение стратегий

На практике комбинируют: большой CACHE_TIME плюс тегированная инвалидация дают и скорость, и актуальность.

Что не попадает в кэш

Не всё должно кэшироваться. Динамические части выносят из-под кэша:

• код в component_epilog.php исполняется всегда — там ставят заголовки и крошки;
• для точечной динамики внутри закэшированного шаблона применяют $APPLICATION->IncludeComponent(..., array('AJAX_MODE' => 'Y')) или отложенные функции;
• данные для эпилога сохраняют через $this->setResultCacheKeys(), чтобы передать их мимо кэша.

Диагностика и типичные ошибки

1. Кэш не сбрасывается. Проверьте, включён ли управляемый кэш и зарегистрированы ли теги.
2. Данные перемешиваются между пользователями. Добавьте зависимые факторы в additionalCacheID.
3. Кэш не создаётся. Убедитесь, что includeComponentTemplate() внутри блока, а CACHE_TIME больше нуля.
4. Медленно даже с кэшем. Перенесите хранилище кэша с файлов на Redis или Memcached.

Для отладки удобен модуль мониторинга производительности, который показывает попадания в кэш и время выполнения компонентов.

При переезде на распределённый кэш важно помнить, что файловое хранилище на нагруженных проектах создаёт огромное число мелких файлов и нагружает дисковую подсистему. Настройка внешнего хранилища задаётся в /bitrix/.settings.php в секции cache, где указывают тип (memcache, redis) и параметры подключения. После переключения обязательно прогоните нагрузочный тест: неверно подобранный размер памяти под кэш приводит к вытеснению записей и падению эффективности до уровня, когда кэш почти не работает.

Итог

Кэширование в компонентах строится вокруг startResultCache() с корректным ключом, дополняется тегированной инвалидацией для актуальности и композитным кэшем для мгновенной отдачи. Главные принципы — включать нужные факторы в ключ кэша, использовать управляемый кэш для сброса по событиям и выносить динамику из-под кэша через эпилог и отложенные функции.

Когда проект упирается в производительность, мы настраиваем многоуровневое кэширование, переносим хранилище на Redis или Memcached и проектируем архитектуру под высокие нагрузки в рамках highload-разработки на 1С-Битрикс.