Current File : //home/bitrix/www/bitrix/modules/main/lang/ru/admin/checklist/QC0050.html
<p>При внедрении технологии кеширования в собственные компоненты 2.0 необходимо четко представлять решаемые задачи:</p>
<ol>
<li>В режиме кеширования компонент не должен выполнять запросы к базе данных. Все данные он получает из кеша. Иногда это правило нарушается (из-за ошибок разработчика или проектировщика) и в режиме кеширования компонент продолжает обращаться к базе данных.</li>
<li>В режиме построения кеша компонент выполняет тщательно оптимизированные запросы к базе данных. Иногда по причине ошибок разработчиков в данном режиме компонент или страницы выполняют огромное число SQL-запросов, например 1000 запросов. </li>
</ol>
<p>Рекомендуется внимательно анализировать запросы, выполняемые компонентом к базе данных и, оптимизируя режимы фильтрации, сортировки и число свойств для выборки - добиться максимальной скорости выполнения запросов, уменьшения их числа и количества обрабатываемых записей в базе данных. </p>
<p>Для анализа SQL запросов компонента удобно использовать SQL команду EXPLAIN. Также крайне важно, анализируя планы выполнения SQL запросов следить, что выборки используют индексы базы данных - что особенно актуально для инфоблоков 2.0, в которых можно добавлять индексы на используемые при фильтрации колонки таблицы свойств элементов инфоблоков.</p>
<p>Также следует закешировать и оптимизировать по вышеописанной методике запросы к базе данных через API, выполняемые из служебных и инициализационных файлов веб-проекта. Иногда бывает так, что на веб-странице размещен один компонент, не выполняющий запросы к базе данных, а в инициализационных файлах проекта для каждого обращения пользователя выполняется 500 SQL запросов, что существенно снижает производительность веб-решение и его устойчивость к нагрузкам.</p>
<p>Иногда составляют и заполняют таблицу со следующей структурой:</p>
<ul>
<li>Страница веб-проекта</li>
<li>SQL-запросов страницы с отключенным кешированием</li>
<li>Число SQL-запросов страницы при включенном кешировании</li>
<li>Проводилась оптимизация SQL-запросов (согласно методике выше)</li>
</ul>
<p>и проверяют все страницы веб-проекта, выявляя неоптимизированные страницы и компоненты на них. Цель - путем доработки и оптимизации добиться того, чтобы в колонке (3) присутствовало близкое к 0 число SQL-запросов (идеально - 0 запросов; число запросов может быть выше при использовании модуля "Веб-аналитика"), в колонке (2) число SQL-запросов было минимально необходимым (например, 150 запросов), а в колонке (4) кратко указано, что оптимизация проводилась. </p>
<p>Иногда подобная контрольная таблица составляется дополнительно для компонентов 2.0 веб-проекта - и в ней описываются характеристики каждого компонента после оптимизации с отключенным/включенным режимом кеширования. </p>
<ol>
<li>Необходимо составить и заполнить вышеописанную таблицу либо, при недостатке времени, выполнить аналогичные замеры на наиболее посещаемых страницах веб-проекта - и, при необходимости, минимизировать нагрузку на базу данных путем кеширования и оптимизации SQL-запросов.</li>
<li>Необходимо удостоверится, что в инициализационных и служебных файлах веб-проекта (т.е. не в компонентах) были оптимизированы по вышеописанной методике все обращения к базе данных через API Bitrix Fraim . Обращения к базе данных напрямую, без использования API Битрикс - не допускаются, в т.ч. потому что данные запросы не "улавливаются" и не доступны для анализа встроенным профилировщиком SQL-запросов.</li>
</ol>
Mini Shell