Автокеширование и управляемое кеширование является важной и неотъемлемой частью работы крупного сайта.
Часто могут проимсходить ситуации, когда кто-то отключил автокеширование по какой-то причине.
Было бы полезно сохранять логи таких действий, по факту это одна маленькая таблица
Часто могут проимсходить ситуации, когда кто-то отключил автокеширование по какой-то причине.
Было бы полезно сохранять логи таких действий, по факту это одна маленькая таблица
Например, некоторые части приложения кешировать в APCu а остальные - в файлы.
файл /bitrix/.settings.php по аналогии с несколькими connections для бд
use \Bitrix\Main\Data\Cache;
// получаем экземпляр класса c конфигурацией cache_config_name
$cache = Cache::createInstance('cache_config_name');
|
файл /bitrix/.settings.php по аналогии с несколькими connections для бд
'cache' => [ 'value' => [ 'default' => [ 'type' => [ 'class_name' => '\\Bitrix\\Main\\Data\\CacheEngineFiles' ] ], 'cache_config_name' => [ 'type' => [ 'class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis', 'extension' => 'redis' ], 'redis' => [ 'host' => '127.0.0.1', 'port' => '6379' ] ], 'sid' => $_SERVER["DOCUMENT_ROOT"]."#01" ] |
Сделать настройку, чтобы часть компонентов, для которых автоматический сброс кэша включен, продолжал бы работать при включенном автокешировании, а для части компонентов сделать так, чтобы они кешировались строго на определенное время и не сбрасывались бы до его истечения ни при каких условиях.
Часто возникает потребность использовать сразу несколько типов кеша. Например, маленькие, но сильно чувствительные к быстродействию данные хранить в оперативной памяти, а тяжёлый HTML-кеш в файлах, но сейчас можно установить только один движок кеша на весь сайт.
Предложение:
Сделать настройки кеширования в settings.php в следующем виде:
В конструкторе Bitrix\Main\Data\Cache, и соответственно старых CPhpCache и CPageCache, передавать в качестве параметра ключ для секции настроек, которые в нём используются.
По умолчанию для всех системных функций будет использоваться кеш по умолчанию.
Для своих модулей, там где это надо, свои настройки с фолбеком на настройки по умолчанию.
Предложение:
Сделать настройки кеширования в settings.php в следующем виде:
... 'cache' => <настройки>, 'cache_extra' => array( 'key1' => <настройки>, 'key2' => <настройки>, ) ... |
По умолчанию для всех системных функций будет использоваться кеш по умолчанию.
Для своих модулей, там где это надо, свои настройки с фолбеком на настройки по умолчанию.
Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.
При большом времени жизни кеша возникает проблема отложенных публикаций.
Например, если в любом типовом решении создать новость или что-то подобное с временем начала активности на несколько минут позже текущего, то при наступлении этого момента времени ничего не случится. Запись появится только при истечении срока кеширования, ручном сбросе кеша или редактировании другого элемента ИБ, что приведет к сбросу тегированного кеша.
Предложение: научить компоненты/API ИБ учитывать время начала и окончания активности.
Например, если в любом типовом решении создать новость или что-то подобное с временем начала активности на несколько минут позже текущего, то при наступлении этого момента времени ничего не случится. Запись появится только при истечении срока кеширования, ручном сбросе кеша или редактировании другого элемента ИБ, что приведет к сбросу тегированного кеша.
Предложение: научить компоненты/API ИБ учитывать время начала и окончания активности.
Ответил 
Жуков Евгений 24.09.2019 18:11:16
Жуков Евгений 24.09.2019 18:11:16
Выйдет в iblock 19.0.0 (возможен сдвиг обновления).
Необходим функционал для компрессии картинок на сайте без потери качества. Для задач по ускорению работы сайта просто незаменимая вещь ведь пока нужно выкачивать все картинки, прогонять через компрессор и обратно грузить тратится уйма времени, особенно если учесть что картинки лежат не только в шаблоне сата, но и в ИБ и в /upload/resize_cache/, а сайт при этом размера с Эльдорадо.
Стандартные методы типа CFile::ResizeImageGet ведь преобразуют в jpeg если у нас другие форматы, например png, а нужно ведь просто оптимизировать все изображения на сайте, то есть пожать их без потерь качества и сохранить в исходный файл с тем же расширением, иначе где-то слетит верстка если будет переконвертация.
Стандартные методы типа CFile::ResizeImageGet ведь преобразуют в jpeg если у нас другие форматы, например png, а нужно ведь просто оптимизировать все изображения на сайте, то есть пожать их без потерь качества и сохранить в исходный файл с тем же расширением, иначе где-то слетит верстка если будет переконвертация.
Дать возможность выбора, какую папку из html кеша удалить.
Сейчас он может удалить только все. и удаляет в алфавитном порядке. И объем хронимого кеша может измерятся гигами. И если надо удалить кеш только с одного раздела то повлиять ты никак не можешь. И выбора у тебя тоже нет.
Сейчас он может удалить только все. и удаляет в алфавитном порядке. И объем хронимого кеша может измерятся гигами. И если надо удалить кеш только с одного раздела то повлиять ты никак не можешь. И выбора у тебя тоже нет.
Наличие любого параметра (?blablabla) у ссылки на подключаемый файл заставляет любое клиентское приложение (браузер, прокси-сервер, мобильное приложение и т.д.) обязательно обратиться за файлом на сервер.
Это RFC.
Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла.
Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.
Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).
Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.
UPDATE 2015-04-01
Теоретическое обоснование и рекомендации от известных разработчиков:
Это RFC.
Сервер, в лучшем случае ответит "304 Not Modified" (но при этом всё равно дёрнет файл с диска/памяти, чтобы проверить) или же полноценный 200 с полной передачей файла.
Ответ сервера в некоторых кешах сохранится, в некоторых (н-р, AppCache) нет.
Соответственно, время модификации, хеш от него или любой другой праметр для cache busting должен быть в имени или пути файла (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b-142712022549372.js), а не в параметре (...template_283cd0022d3edc763e34cc00a91e7e1b/template_283cd0022d3edc763e34cc00a91e7e1b.js?142712022549372).
Проверить очень просто: при повторном открытии страницы сайта на сервер должен идти только 1 запрос - на саму страницу, а все остальные файлы должны браться из кеша браузера.
UPDATE 2015-04-01
Теоретическое обоснование и рекомендации от известных разработчиков:
- Application cache
Never access cached files by using traditional GET parameters (like other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network.
- В Apache
- В Nginx
- Rails Asset Pipeline
- Модуль Web Optimizer для 1С-Битрикс, многие идеи из которого перешли "в коробку"
- Все проекты TM (.)
Пока идет обмен с 1С, где-то плачет один заказчик.
Когда Битрикс сделал тегированный кеш - была допущена огромная недоработка. Многие серьезные сайты стали работать существенно медленнее.
------------
С одной стороны здорово, что описания и цены на сайте сразу обновляются при изменении элемента.
Но если идет обмен с 1С, то сайт фактически лежит. Потому что кеш всех компонентов инфоблока сбрасывается обменом, и ходить по сайту невозможно.
Представьте, сколько времени надо для записи 10000 легковых шин в инфоблок?
Умные фильтры особенно усугубляют производительность. Тегированный кеш приходится полностью отключать.
-------------
Идея 1.
Добавьте возможность в компоненте указать, что в нем тегированный кеш не используется.
Фильтр, который показывает все возможные варианты особенно тормозит, пока идет обмен с 1С.
Я бы в нем отключил тегированный кеш и использовал обычный кеш. Никто не заметит, что шаблон фильтра только раз в три часа обновляется.
Идея 2.
Сделайте событие при сбросе кеша по тегу.
Я бы написал обработчик запрещающий сбрасывать кеш по тегу, пока идет обмен с 1С. А сбросил бы кеш позже сам.
Когда Битрикс сделал тегированный кеш - была допущена огромная недоработка. Многие серьезные сайты стали работать существенно медленнее.
------------
С одной стороны здорово, что описания и цены на сайте сразу обновляются при изменении элемента.
Но если идет обмен с 1С, то сайт фактически лежит. Потому что кеш всех компонентов инфоблока сбрасывается обменом, и ходить по сайту невозможно.
Представьте, сколько времени надо для записи 10000 легковых шин в инфоблок?
Умные фильтры особенно усугубляют производительность. Тегированный кеш приходится полностью отключать.
-------------
Идея 1.
Добавьте возможность в компоненте указать, что в нем тегированный кеш не используется.
Фильтр, который показывает все возможные варианты особенно тормозит, пока идет обмен с 1С.
Я бы в нем отключил тегированный кеш и использовал обычный кеш. Никто не заметит, что шаблон фильтра только раз в три часа обновляется.
Идея 2.
Сделайте событие при сбросе кеша по тегу.
Я бы написал обработчик запрещающий сбрасывать кеш по тегу, пока идет обмен с 1С. А сбросил бы кеш позже сам.
Ответил 
17.11.2014 14:56:02
17.11.2014 14:56:02
Как бы механизм отключения тегирования у инфоблоков есть, или он не решает вашей проблемы:
CIblock::DisableTagCache($iblock_id) |
Ответил
Жуков Евгений 21.04.2015 19:06:11
Жуков Евгений 21.04.2015 19:06:11
iblock 15.0.7 - добавлена возможность управления сбросом тегированного кеша на хите. Добавлены методы CIBlock::enableClearTagCache(), CIBlock:: DisableClearTagCache(), CIBlock::isEnabledClearTagCache(), CIBlock::clearIblockTagCache().
Ответил
Жуков Евгений 14.06.2019 17:24:02
Жуков Евгений 14.06.2019 17:24:02
Связка catalog 19.0.0 + iblock 19.0.0 - добавлено управление сбросом тегированного кеша при обмене с 1С.
© 2001-2022 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
