Кеширование компонента
Метод startResultCache() проверяет наличие кеша компонента и при его отсутствии выполняет выборку с сохранением вывода в /bitrix/cache/. Уникальные факторы выборки (ID пользователя, фильтры, страница пагинации) передаются вторым аргументом ключа кеша, а для инвалидации при обновлении данных инфоблока регистрируют теги в TaggedCache.
Прогресс хранится в этом браузере. Войдите, чтобы сохранить его в аккаунте.
Что нужно понимать
-
1
Настройка кеширования
-
2
Теги кеша
-
3
Инвалидация кеша
Материалы
Официальная документация
Проверь себя
Пользователь видит в компоненте чужие данные. Где искать причину?
В ключе кеша. Компонент кешируется по параметрам, шаблону и группам пользователя, а всё, что влияет на результат сверх этого (ID пользователя, GET-параметр фильтра, город), нужно самому передать вторым аргументом startResultCache().
Почему код в result_modifier.php не сработал, а в component_epilog.php сработал?
result_modifier.php выполняется только при формировании кеша, вместе с шаблоном. component_epilog.php выполняется на каждом хите, в том числе когда HTML взят из кеша.
Зачем вызывать SetResultCacheKeys(), если компонент и так работает?
Без него в кеш попадает весь $arResult, включая данные, нужные только шаблону. Ключи ограничивают то, что доступно в component_epilog.php, и уменьшают размер файлов в /bitrix/cache.
Чем тегированный кеш лучше короткого времени жизни?
Кеш живёт долго и сбрасывается точно в момент изменения данных: при правке элемента инфоблока ядро сбрасывает все кеши с тегом iblock_id_N. Короткое время жизни просто чаще перестраивает кеш и грузит базу.
Не сходится?
Спросите Домового: он знает документацию и материалы сайта по этой теме. Ответит сразу.
Нужен живой разбор?
Консультация автора BXMax: созвон один на один, 90 минут на вашу задачу по теме «Кеширование компонента».
Знаете материал лучше? Предложите ссылку: после проверки она появится в этом разделе.
Войти, чтобы предложить