Рейтинг: 7  
На голосовании
Предложил Itachi261092 05.03.2018 13:07:38

Автоудаление устаревших файлов папки upload

Для кого то это может и не проблема, но то, что за папкой upload ядро битрикса никак не следит - это факт. При использовании разных решений, шаблонов, и функции ResizeImageGet, например, папка upload заполняется множеством копий картинок, которые потом, например, при выгрузке заменяются. Для них создаются новые копии. А старые никуда не исчезают. Битрикс удаляет только оригинальный файл, а все ресайзы оставляет. Для крупных каталогов это огромная проблема. Объём папки Upload может вырастать до гигантских размеров, и нет ни одного инструмента внутри админки чтобы это как-то контролировать.

Предлагаю, например, в разделе настройки -> настройки продукта -> автокеширование добавить вкладку "Папка upload" и добавить настройки для контроля картинок этой папки. Дать возможность удалять все ресайзы и копии оригинальных файлов, устаревшие файлы, на которые нет ссылок в элементах и разделах инфоблоков, и настраивать автоматическое удаление по таймауту, как для кеша. Если картинку давно никто не запрашивает - она удаляется.
Рейтинг: 0.3403  
На голосовании
Предложил Бугай Максим 04.10.2017 04:22:17

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

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

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

По умолчанию для всех системных функций будет использоваться кеш по умолчанию.
Для своих модулей, там где это надо, свои настройки с фолбеком на настройки по умолчанию.
Рейтинг: 1.185  
На голосовании
Предложил Клёпов Роман 02.11.2016 14:47:20

Очистка файлов кеша для отдельного сайта

Добрый день, коллеги!

Периодически приходится чистить весь кеш (Очистка файлов кеша - Все). В случае многосайтовости очень неудобно удалять абсолютно весь кеш, без выбора отдельного сайта.

Добавьте, пожалуйста опцию выбора сайта, кеш которого надо удалить.
Рейтинг: 3.9726  
Внедрено
Предложил Валерий Чебан 06.10.2016 18:14:12

bitrix:catalog.element - убрать лишние данные из кеша

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

Нужно это поправить.    

1/ Массив $arResult['SECTION']  и подмассив $arResult["SECTION"]["PATH"]:
зачем сохранять в кеше все поля секций, даже SEARCHABLE_CONTENT?
для сео они все не нужны.

2/ Зачем сохранять все свойства элемента в кеш и даже пустые?
Массив $arResult['PROPERTIES'] - зачем все сохраняются? для сео и прочего лишь некоторые ведь нужны...
Надо лишние убирать.

После удаления лишнего из кеша, объем этого самого кеша уменьшается с 3мб до 90кб.
Считаю, что нужно внедрить это в компонент bitrix:catalog.element.

Пример решения через result_modifier.php компонента bitrix:catalog.element:
// clear unused cache fields
foreach ($arResult['PROPERTIES'] as $k => $prop) {
   if (trim($prop['VALUE']) == '') {
      unset($arResult['PROPERTIES'][$k]);
   }
}

$arDeleteSectionKeys = array('SEARCHABLE_CONTENT', '~SEARCHABLE_CONTENT');
foreach ($arResult['SECTION'] as $k => $s) {
   if ($k == 'PATH') {
      foreach ($s as $ks => $ss) {
         foreach ($ss as $kss => $ss2) {
            if (in_array($kss, $arDeleteSectionKeys)) {
               unset($arResult['SECTION'][$k][$ks][$kss]);
            }
         }
      }
   } else if (in_array($k, $arDeleteSectionKeys)) {
      unset($arResult['SECTION'][$k]);
   }
} 
Рейтинг: 0.0185  
Ответил Жуков Евгений 25.10.2016 15:08:47
iblock 16.6.1. изменения затронут так же news.detail.
п.1 Оставили только часть полей
п.2. Ключ PROPERTIES больше не сохраняется вообще - в нем больше нет необходимости
Рейтинг: 1.6143  
Новая
Предложил Шумко Виталий 14.03.2016 12:59:44

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

Необходим функционал для компрессии картинок на сайте без потери качества. Для задач по ускорению работы сайта просто незаменимая вещь ведь пока нужно выкачивать все картинки, прогонять через компрессор и обратно грузить тратится уйма времени, особенно если учесть что картинки лежат не только в шаблоне сата, но и в ИБ и в /upload/resize_cache/, а сайт при этом размера с Эльдорадо.
Стандартные методы типа CFile::ResizeImageGet ведь преобразуют в jpeg если у нас другие форматы, например png, а нужно ведь просто оптимизировать все изображения на сайте, то есть пожать их без потерь качества и сохранить в исходный файл с тем же расширением, иначе где-то слетит верстка если будет переконвертация.
Рейтинг: 2.0129  
Новая
Предложил Валерий Чебан 03.07.2015 19:21:26

Кеш: добавить произвольную серриализацию

сделать возможным указывать свой режим сериализации, отличный от стандартного serialize() --> unserialize()


Еще по теме:

apc_store() - позволяет хранить переменную. Сама функция серриализует данные.
Можно подключить igbinary и указать apc.serializer=igbinary

при этом apc_store() будет использовать серриализатор igbinary (а не стандартный)

В коде главного модуля сейчас зашито:
$arAllVars = serialize($arAllVars);
apc_store($baseDirVersion."|".$initDirVersion."|".$filename, $arAllVars, intval($TTL));
Поэтому настройка apc.serializer=igbinary просто игнорируется.
Нужно это убрать.

К, примеру, memcached этого недостатка лишен, и можно указать memcached.serializer = igbinary, и в ядре не происходит предварительной серриализации массива стандартной функцией serialize()
Рейтинг: 52.7169  
На голосовании
Предложил Степанченко Александр 15.10.2013 14:03:49

Вынос счётчиков(SHOW_COUNTER) в отдельную таблицу

Сейчас каждый просмотр элемента инфоблоков, вызывает UPDATE таблицы iblock_element. Вынос статистики просмотров в отдельную таблицу позволит значительно повысить эффективность работы mysql за счёт кеша запросов.
MySQL хранит в кеше список таблиц, выборка из которых закеширована. Если в любой из таблиц, выборка из которой есть в кеше, проиcходят изменения (вставка или изменение строк), то MySQL удаляет из кеша такие выборки. Такой подход ускоряет работу MySQL, но может быть неэффективным для систем с большим количеством запросов на изменение таблиц.
Оптимизация для подобных таблиц — вынести часто изменяющиеся данные в отдельную таблицу.
Это стоит сделать не только для инфоблоков, но и рекламы(просмотры баннеров) и форумов(просмотры тем) блогов(просмотры записи) и т.п.
Рейтинг: 11.8296  
На голосовании
Предложил Чернышов Антон 22.02.2013 12:05:45

Упорядочить папки хранения кеша

Сейчас файлы кеша разбросаны в папки cache, cache_image, managed_cache, stack_cache. Следует их упорядочить в одну папку cache c подпапками.
Рейтинг: -6.9735  
На голосовании
Предложил Постоев Олег 03.02.2013 16:38:29

Добавить к компонентам параметр "Значимые переменные"

Что бы кеш шаблона компонента формировался с учетом значений дополнительных переменных.
Например при смене города на сайте добавляется переменная $_REQUEST["CITY_CODE"], в зависимости от значений которой и выводился бы кеш шаблона компонента.
Рейтинг: 8.1438  
Новая
Предложил Born 04.07.2012 19:39:44

Зачистка всех кешей дотла

Добавить в публичное документированное API функцию BXClearCache_ващще_всё :)
т.е. одним махом чистить не только /cache, но и /managed и /stack кеши, и, желательно, без установки задержек.
Думаю, будет востребовано, кеширование становится все изощреннее, с соотв. количеством багов, фикс тех багов дело туманное и, видимо, очень далекого будущего, а работать надо.
Жизненный пример - данные импортируем из 1с, на их основе с помощью API создаем скидки, прикрепляем товары, потом транслируем скидки на дополнительные сайты многосайтовости, предыдущие удаляем и пр., т.е. все кодом. Тем не менее, плясок вокруг кнопочек в админке избежать не удается. Бедолага Заказчик, учить его грохать кеши папками нельзя, снесет полсистемы. Вот и запускает скрипт, бежит чистит, заходит в каждую скидку пересохранять, потом второй скрипт и прочее шаманство. А так грохнуть бы все где надо во скрипте, и все счаастливы ;)
Рейтинг: 41.4165  
На голосовании
Предложил Долганин Антон 29.03.2012 18:37:27

Мемкеш: BX_CACHE_SID делать равным LICENSE_KEY по умолчанию и прописать это в документации

На данный момент в документации советуется ставить BX_CACHE_SID  равным DOCUMENT_ROOT. Это неправильно, так как если доменов несколько на одном Битриксе, получаются аномалии с кешем. Пример проблемного случая тут: http://dev.1c-bitrix.ru/community/forums/messages/forum7/topic43586/message235013/#message235013
А если привяжемся к ключу, то у нас кеш всегда уникальный для одной коробки получится.