При внедрении технологии кеширования в собственные компоненты 2.0 необходимо четко представлять решаемые задачи:

  1. В режиме кеширования компонент не должен выполнять запросы к базе данных. Все данные он получает из кеша. Иногда это правило нарушается (из-за ошибок разработчика или проектировщика) и в режиме кеширования компонент продолжает обращаться к базе данных.
  2. В режиме построения кеша компонент выполняет тщательно оптимизированные запросы к базе данных. Иногда по причине ошибок разработчиков в данном режиме компонент или страницы выполняют огромное число SQL-запросов, например 1000 запросов.

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

Для анализа SQL запросов компонента удобно использовать SQL команду EXPLAIN. Также крайне важно, анализируя планы выполнения SQL запросов следить, что выборки используют индексы базы данных - что особенно актуально для инфоблоков 2.0, в которых можно добавлять индексы на используемые при фильтрации колонки таблицы свойств элементов инфоблоков.

Также следует закешировать и оптимизировать по вышеописанной методике запросы к базе данных через API, выполняемые из служебных и инициализационных файлов веб-проекта. Иногда бывает так, что на веб-странице размещен один компонент, не выполняющий запросы к базе данных, а в инициализационных файлах проекта для каждого обращения пользователя выполняется 500 SQL запросов, что существенно снижает производительность веб-решение и его устойчивость к нагрузкам.

Иногда составляют и заполняют таблицу со следующей структурой:

и проверяют все страницы веб-проекта, выявляя неоптимизированные страницы и компоненты на них. Цель - путем доработки и оптимизации добиться того, чтобы в колонке (3) присутствовало близкое к 0 число SQL-запросов (идеально - 0 запросов; число запросов может быть выше при использовании модуля "Веб-аналитика"), в колонке (2) число SQL-запросов было минимально необходимым (например, 150 запросов), а в колонке (4) кратко указано, что оптимизация проводилась.

Иногда подобная контрольная таблица составляется дополнительно для компонентов 2.0 веб-проекта - и в ней описываются характеристики каждого компонента после оптимизации с отключенным/включенным режимом кеширования.

  1. Необходимо составить и заполнить вышеописанную таблицу либо, при недостатке времени, выполнить аналогичные замеры на наиболее посещаемых страницах веб-проекта - и, при необходимости, минимизировать нагрузку на базу данных путем кеширования и оптимизации SQL-запросов.
  2. Необходимо удостоверится, что в инициализационных и служебных файлах веб-проекта (т.е. не в компонентах) были оптимизированы по вышеописанной методике все обращения к базе данных через API Bitrix Fraim . Обращения к базе данных напрямую, без использования API Битрикс - не допускаются, в т.ч. потому что данные запросы не "улавливаются" и не доступны для анализа встроенным профилировщиком SQL-запросов.