Рейтинг: 0.8902  
Новая
Предложил Пользователь 571339 12.01.2022 09:12:50

Хранение логов по включению и отключению автокеширования

Автокеширование и управляемое кеширование является важной и неотъемлемой частью работы крупного сайта.

Часто могут проимсходить ситуации, когда кто-то отключил автокеширование по какой-то причине.

Было бы полезно сохранять логи таких действий, по факту это одна маленькая таблица
Рейтинг: 2  
Новая
Предложил Пользователь 17890 04.10.2019 15:53:59

Сделать возможность кешировать данные в различных местах под одним ядром

Например, некоторые части приложения кешировать в APCu а остальные - в файлы.

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"
      ]   
Рейтинг: 1  
Новая
Предложил Пользователь 92319 15.03.2018 17:23:13

Одновременное автокеширование и кеширование по сроку истечения

Сделать настройку, чтобы часть компонентов, для которых автоматический сброс кэша  включен, продолжал бы работать при включенном автокешировании, а для  части компонентов сделать так, чтобы они кешировались  строго на определенное время и не сбрасывались бы до его истечения ни при каких условиях.
Рейтинг: 0.3403  
На голосовании
Предложил Пользователь 91948 04.10.2017 04:22:17

Несколько типов кеша на одном сайте

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

Предложение:
Сделать настройки кеширования в settings.php в следующем виде:
...
'cache' => <настройки>,
'cache_extra' => array(
  'key1' => <настройки>,
  'key2' => <настройки>,
)
...
В конструкторе Bitrix\Main\Data\Cache, и соответственно  старых  CPhpCache и CPageCache, передавать в качестве параметра ключ для секции настроек, которые в нём используются.

По умолчанию для всех системных функций будет использоваться кеш по умолчанию.
Для своих модулей, там где это надо, свои настройки с фолбеком на настройки по умолчанию.
Рейтинг: 1  
Новая
Предложил Пользователь 49746 07.09.2016 11:12:19

Дать возможность подключать эпилог компонента самостоятельно

Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=3053), подключение шаблона можно размещать как в кешируемой области, так и вне её.
При подключении шаблона в кешируемой области собственного компонента со сложным кешированием шаблон не отрабатывает вообще - сразу выводится html-кеш.
Разница в том, что в стандартных компонентах используется метод StartResultCache и при этом template.php кешируется полностью и выводится как html-кеш. При этом из кеша на хите достаются переменные VARS из файла кеша и передаются в component_epilog.php, что не происходит, если строить свое кеширование согласно вышеуказанному курсу.  
Покопавшись в исходниках, выяснил, что в метод startResultCache() вшит также метод includeComponentEpilog(), которого нет в классах кастомного кеширования и в документации.
При этом входящие данные для него от родительского компонента в своем дочернем компоненте получить нельзя, так как свойство, в котором хранится путь и данные для метода includeComponentEpilog() лежат в родительском свойстве __component_epilog, которое имеет модификатор доступа private и недоступен в потомке.
В связи с этим кастомное кеширование получается неполноценным, т.к. для использования в шаблонах component_epilog, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.  
Рейтинг: 15.3461  
Внедрено
Предложил Пользователь 273513 17.06.2016 16:58:21

Сброс кеша при наступлении даты начала/окончания активности элемента ИБ

При большом времени жизни кеша возникает проблема отложенных публикаций.

Например, если в любом типовом решении создать новость или что-то подобное с временем начала активности на несколько минут позже текущего, то при наступлении этого момента времени ничего не случится. Запись появится только при истечении срока кеширования, ручном сбросе кеша или редактировании другого элемента ИБ, что приведет к сбросу тегированного кеша.

Предложение: научить компоненты/API ИБ учитывать время начала и окончания активности.
Рейтинг: 0  
Ответил Жуков Евгений 24.09.2019 18:11:16
Выйдет в iblock 19.0.0 (возможен сдвиг обновления).
Рейтинг: 1.6143  
Новая
Предложил Пользователь 205682 14.03.2016 12:59:44

Компрессия изображений на сайте

Необходим функционал для компрессии картинок на сайте без потери качества. Для задач по ускорению работы сайта просто незаменимая вещь ведь пока нужно выкачивать все картинки, прогонять через компрессор и обратно грузить тратится уйма времени, особенно если учесть что картинки лежат не только в шаблоне сата, но и в ИБ и в /upload/resize_cache/, а сайт при этом размера с Эльдорадо.
Стандартные методы типа CFile::ResizeImageGet ведь преобразуют в jpeg если у нас другие форматы, например png, а нужно ведь просто оптимизировать все изображения на сайте, то есть пожать их без потерь качества и сохранить в исходный файл с тем же расширением, иначе где-то слетит верстка если будет переконвертация.
Рейтинг: 3.2724  
На голосовании
Предложил Пользователь 20003 17.08.2015 17:14:58

Композитный сайт - очистка кеша

Дать возможность выбора, какую папку из html кеша удалить.
Сейчас он может удалить только все. и удаляет в алфавитном порядке.  И объем хронимого  кеша может измерятся гигами.  И если надо удалить  кеш только с одного раздела то повлиять ты никак не можешь. И выбора у тебя тоже нет.
Рейтинг: 0.1833  
Ответил 21.08.2015 12:26:40
Здравствуйте Николай.

В данный момент это можно сделать несколько экзотично, но можно:

Через управление структурой. Зайти в папку /bitrix/html_pages/ и выбрать нужные поддиректории.

Спасибо за идею.
Рейтинг: 0.239  
На голосовании
Предложил Пользователь 9746 25.03.2015 12:58:20

Убрать параметр в ссылках на css и js

Наличие любого параметра (?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

Теоретическое обоснование и рекомендации от известных разработчиков:
Реализации:
Первые попашиеся "правильные" сайты:
Font-Awesome планирует в 5-й версии перенести параметр в название файла шрифта https://github.com/FortAwesome/Font-Awesome/issues/5231 и https://github.com/FortAwesome/Font-Awesome/issues/3286
Рейтинг: 1.5689  
Внедрено
Предложил Пользователь 25773 15.11.2014 20:23:24

Усовершенствовать механизм тегированного кеша. Есть случаи, когда в инфоблоках его сбрасывать не надо

Пока идет обмен с 1С, где-то плачет один заказчик.

Когда Битрикс сделал тегированный кеш - была допущена огромная недоработка. Многие серьезные сайты стали работать существенно медленнее.

------------

С одной стороны здорово, что описания и цены на сайте сразу обновляются при изменении элемента.

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

Представьте, сколько времени надо для записи 10000 легковых шин в инфоблок?

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

-------------

Идея 1.

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

Фильтр, который показывает все возможные варианты особенно тормозит, пока идет обмен с 1С.

Я бы в нем отключил тегированный кеш и использовал обычный кеш. Никто не заметит, что шаблон фильтра только раз в три часа обновляется.






Идея 2.


Сделайте событие при сбросе кеша по тегу.

Я бы написал обработчик запрещающий сбрасывать кеш по тегу, пока идет обмен с 1С. А сбросил бы кеш позже сам.
Рейтинг: -1  
Ответил 17.11.2014 14:56:02
Как бы механизм отключения тегирования у инфоблоков есть, или он не решает вашей проблемы:
CIblock::DisableTagCache($iblock_id)
 
Рейтинг: 0.6892  
Ответил Жуков Евгений 21.04.2015 19:06:11
iblock 15.0.7 - добавлена возможность управления сбросом тегированного кеша на хите. Добавлены методы CIBlock::enableClearTagCache(), CIBlock:: DisableClearTagCache(), CIBlock::isEnabledClearTagCache(), CIBlock::clearIblockTagCache().
Рейтинг: 0  
Ответил Жуков Евгений 14.06.2019 17:24:02
Связка catalog 19.0.0 + iblock 19.0.0 - добавлено управление сбросом тегированного кеша при обмене с 1С.