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



файл /bitrix/.settings.php по аналогии с несколькими connections для бд

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

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

Предложение:
Сделать настройки кеширования в settings.php в следующем виде:В конструкторе Bitrix\Main\Data\Cache, и соответственно  старых  CPhpCache и CPageCache, передавать в качестве параметра ключ для секции настроек, которые в нём используются.

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

Добрый день.
Возник момент с кастомным кешированием в своем компоненте.
Согласно этому курсу (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, нужно подключение шаблона обязательно выводить из кешируемой области.
Прошу дать возможность разработчику самостоятельно подключать эпилог компонента в своем компоненте.  

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

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

Предложение: научить компоненты/API ИБ учитывать время начала и окончания активности.

Необходим функционал для компрессии картинок на сайте без потери качества. Для задач по ускорению работы сайта просто незаменимая вещь ведь пока нужно выкачивать все картинки, прогонять через компрессор и обратно грузить тратится уйма времени, особенно если учесть что картинки лежат не только в шаблоне сата, но и в ИБ и в /upload/resize_cache/, а сайт при этом размера с Эльдорадо.
Стандартные методы типа 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

Теоретическое обоснование и рекомендации от известных разработчиков:

• http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
• https://github.com/paulirish/html5-boilerplate/wiki/cachebusting/e58c07be9f0a43da08e766b21514f81ece24fa17
• http://webassets.readthedocs.org/en/latest/expiring.html#expire-using-a-querystring
• 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.

  https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache#Gotchas
  

Реализации:

• В Apache https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess#L982-L998
• В Nginx https://github.com/h5bp/server-configs-nginx/blob/master/h5bp/location/cache-busting.conf
• Rails Asset Pipeline http://guides.rubyonrails.org/asset_pipeline.html#what-is-fingerprinting-and-why-should-i-care-questionmark
• Модуль Web Optimizer для 1С-Битрикс, многие идеи из которого перешли "в коробку" https://dev.1c-bitrix.ru/community/blogs/rsv-dev/1732.php
  

Первые попашиеся "правильные" сайты:

• Все проекты TM (http://habrahabr.ru/, http://megamozg.ru/, http://geektimes.ru/ и т.д.)
• https://twitter.com/
• https://www.facebook.com/
  

Font-Awesome планирует в 5-й версии перенести параметр в название файла шрифта https://github.com/FortAwesome/Font-Awesome/issues/5231 и https://github.com/FortAwesome/Font-Awesome/issues/3286

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

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

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

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

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

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

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

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

Идея 1.

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

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

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






Идея 2.

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

Я бы написал обработчик запрещающий сбрасывать кеш по тегу, пока идет обмен с 1С. А сбросил бы кеш позже сам.

Есть компонент A который выводит инфо об элементе инфоблока.
Вывод кешируется по ID элемента.
Иногда возникает необходимость сбросить кеш компонента A когда в компоненте B происходит какое-то событие.
К сожалению, CBitrixComponent::clearComponentCache сбрасывает кеш всего компонента.
А необходимо иметь возможность сбросить кеш только частично.
Например компонентом A закешировано 100 элементов.
Если я сброшу весь кеш компонента A через CBitrixComponent::clearComponentCache, то при следующих обращениях к компоненту, его кеш будет заполняться заново, даже если был изменен только один элемент. А если бы была возможность указывать ID кеша, то можно было бы сбросить только часть кеша компонента.

На сайтах где много страниц - кеш меню очень сильно разрастается, инодга на несколько гигабайт, что сильно тормозит работу сайта, так как на каждую страницу Битрикс зачем-то создает свой кеш меню.

Это оказывается можно выключить, если добавить скрытый недокументированный параметр
"CACHE_SELECTED_ITEMS" => "N"
В интернете аж одна строчка про этот параметр:
http://dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&LESSON_ID=5402

но из за незнания этих особенностей все сайты на Битрикс (даже самые простые) где много страниц - могут занимать Гигабайты (причем большую часть места занимает именно кеш).

Если добавить этот параметр - то тогда для меню создается всего один файл кеша для всех страниц сайта.

Но если оставить как есть по умолчанию - то ваше меню будет разрастаться и распухать как на дрожжах, так как при каждом посещении новой страницы (при каждом разном $APPLICATION->GetCurPage() ) ваш кеш будет пухнуть.

Например, даже если у вас в меню всего 5 страниц, но зато 1000 товаров, то кеш меню создастся 1000 раз.

Зачем так мучать сервер? Выключите, пожалуйста, этот параметр по умолчанию, или добавьте константу которая будет эту штуку отключать, или хотя-бы вынесете в параметры меню, чтобы можно было отключать ее одним кликом мышки.

Предлагаю реализовать функционал триггера для инвалидации тегированного кеша при наступлении даты/времени в свойстве типа дата/время с установленной галочкой "Инвалидация кеша"

Это необходимо для реализации всевозможных акций которые стартуют с определённого времени. Ну и ещё можно для чего либо использовать)

В стандартных компонентах к параметрам кеширования
CACHE_TYPE
CACHE_TIME
CACHE_GROUPS

добавить еще один параметр
CACHE_PARAM

в который можно записывать произвольные данные (число, строка) и будет изменяться идентификатор кеша компонента.
Для чего это можно использовать:
например, полностью устраивает компоннет bitrix:catalog.element, но нужно чтобы в зависимости от выбранного параметра на странице этот компонент (через логику result_modifier) выбирал или обрабатывал дополнительные данные.

Если компонент работает в режиме автокеширования, то какие бы мы параметры адресной строки не меняли, кеш будет один и тот-же, до тех пор пока мы не изменим входные параметры компонента.

Чтобы не создавать дополнительные параметры для этого случая, было бы удобно, чтобы был стандартный зарезервированный параметр CACHE_PARAM, в который можно поместить какие-то данные, и идентификатор кеша изменился бы.

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

Идея

Сделать обертку над функцией GetCurPageParam, которая бы автоматически удаляла из генерируемого урла такие параметры, как show_page_exec_time, bitrix_include_areas, clear_cache, и прочие стандартные переменные Битрикс.

Кому и зачем нужно

Разработчик заходит на страницу и сбрасывает кеш через clear_cache. Весь кеш удаляется и генерируется заново. Если компоненты выводили ссылки с помощью GetCurPageParam, и там не прописано удаление переменной clear_cache, эта переменная попадает в ссылку и ее увидит каждый пользователь на сайте. Решения три
- сбрасывать кеш только в админке
- каждый раз писать, чтобы GetCurPageParam удаляла clear_cache
- сделать обертку над GetCurPageParam, которая будет это делать сама, и вызывать уже ее.

Часто кастомизация компонента (копирование в свое пространство имен и дальнейшая модификация) делается ради пары-тройки строк кода, которые добавляют в ключ кеша некоторые дополнительные параметры.
Предлагаю избавить нас всех от этих мучений.
Каким образом?
Предлагаю ввести в параметры компонента настройку, назовем ее CACHE_KEYS - множественное поле типа "строка". В ней разработчики будут, так же как в параметре FILTER_NAME, прописывать ИМЯ переменной. В самом компоненте значения будут вытаскиваться из этих переменных и передаваться в метод StartResultCache.
Избежать всеобщей модификации всех компонентов можно, если добавлять параметр CACHE_KEYS автоматически всегда, когда включено кеширование, а перед вызовом компонента добавлять значения в глобальные переменные, откуда и доставать внутри метода StartResultCache.

В админке на странице очистки файлов кеша очень не хватает даты последнего сброса кеша.
Хотелось бы примерно так.

Сейчас файлы кеша разбросаны в папки cache, cache_image, managed_cache, stack_cache. Следует их упорядочить в одну папку cache c подпапками.

Что бы кеш шаблона компонента формировался с учетом значений дополнительных переменных.
Например при смене города на сайте добавляется переменная $_REQUEST["CITY_CODE"], в зависимости от значений которой и выводился бы кеш шаблона компонента.