Сейчас если я через БУС создаю сайт24 и каждый раз при добавлении/редактировании своего кастомного блока приходится сбрасывать кэш всего сайта чтобы увидеть изменения.
Если сайт огромный то удаляется очень много закешированных файлов не относящихся к сайтам24.

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

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

Много раз сталкивался и продолжаю до сих пор со следующей проблемой, решение которой и предлагаю решить в очередном релизе.

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

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

Битрикс считает только размер базы данных и пользовательских файлов, т.е. публичной части сайта. Причем делает он это не путем пересчета, а путем вычисления при операции добавления или удаления некого элемента через Битрикс. Он просто прибавляет или отнимает соответствующую цифру от имеющейся в базе. В случае, когда операция проводится в обход Битрикса, например чистка кэша средствами операционной системы, соответствующих вычислений не происходит. Наступает момент, когда даже при незабитом диске Битрикс начинает выдавать ошибку о том, что сайт достиг максимального размера. Проблема решается ручным пересчетом из настроек главного модуля. Хотя неплохо было бы, чтобы расчет производился не путем математических расчетов, а путем фактического пересчета путем сканирования папок битрикса.

Наш сайт (mtg-biz.ru) меняется достаточно редко. Фактически только новости и список установок. Однако, каждый раз происходит обращение к нашему серверу, даже, если не было изменений.

Почему бы не сделать технологию, которая будет отслеживать изменение кэша и возвращать браузеру 304, когда страница не менялась. Яркий пример - наша главная страница. Новости меняются самое частое раз в две недели.

Конечно, такое кэширование должно учитывать "активность" - часть новостей создана заранее и отображается после. Однако, сам же компонент кэшируется... Значит, можно кэшировать и целиком остальную страницу.

Очень жаль что bitrix не в полную поддерживает данный сервис, наблюдаются некоторые глюки в работе скриптов, при включении сжатия и оптимизации.

А там и оптимизация и асинхронная загрузка и кэширование на их сервера -  JS, CSS, HTML; и CDN и защита от DDOS  и много многое другое...



Очень большая просьба оптимизируйте структуру и скрипты под данный сервис.

P.S. Я смотрю добавления emoji намного более светлая идея и проблема, нежели доступность/скорость  сайта. Минусуем дальше.

P.S.S И я думал тут не учитывается мнение разрабов битрикса, а только пользователей продукта. Вы конечно не заинтересованы продвигать данный сервис у вас же есть свой CDN, поэтому корректнее было бы пройти просто мимо, да Михаил?

Вот, к примеру, пустой news.list, но занимает почему-то 93Кб. Из $arResult все вырезано по максимуму.



Бывают и гораздо худшие случаи, когда кэш может занимать несколько мегабайт Стандартный forum.topic.last так когда-то чудил.
При большом кэше соответственно увеличивается время работы компонента.
Вот и хотелось бы как-то заглянуть в файлы кэша в сыром виде, чтобы понять куда копать и что еще можно урезать.

Для стандартных компонентов при выставлении параметра "Учитывать права доступа" позволять определять группы пользователей для которых не нужно кэширование компонента. Это позволит сэкономить место на диске (при файловом кэшировании) и предоставит больше места для кэша страниц для обычных посетителей сайта в оперативной памяти (при APC-кэшировании)

Модераторам просьба перенести идею в категорию "БУС", забыл выбрать.