Highload и битрикс. 17 “точек ада” - alma-com/wiki-bitrix GitHub Wiki

  1. Не показывать постраничную навигацию по данным, которых больше 10 тысяч единиц.

  2. Не “показывать количество в категории”. Если вам это число позарез нужно, сделайте поле у категории, пересчитывайте агентом, и показывайте данные из этого поля. Денормализация – друг оптимизатора.

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

  4. Не включать в табличном просмотре в админпанели вывод многих свойств в списке. Только Название и ID, можно цену.

  5. В настройках свойств не ставить галочку "Выводить на странице списка элементов поле для фильтрации по этому свойству".

  6. Использовать штатные свойств таблицы инфоблоков: Created by, ID, XML_ID и CODE вместо собственных свойств для связи сущностей. Эти свойства имеют встроенные индексы:

KEY `ix_iblock_element_1` (`IBLOCK_ID`,`IBLOCK_SECTION_ID`), 
KEY `ix_iblock_element_4` (`IBLOCK_ID`,`XML_ID`,`WF_PARENT_ELEMENT_ID`), 
KEY `ix_iblock_element_3` (`WF_PARENT_ELEMENT_ID`), 
KEY `ix_iblock_element_code` (`IBLOCK_ID`,`CODE`)

  1. Не использовать пользовательские поля (UF) категорий.

  2. Не хранить большой объем текстовой информации в preview text и detail text, это делает одну строку таблицы элементов инфоблока легче и ускоряет выборки. Вынести поля описаний в таблицу свойств. Можно даже посоветовать написать обработчик события или агента, который будет чистить эти поля.

  3. Для полнотекстового поиска по сайту использовать sphinx. Он намного ускоряет поиск и снижает нагрузку. Правда, качество поиска не меняется.

  4. Делать индексы на все, по чему выполняется медленная сортировка или поиск. Да, и поменьше сортировок и поисков. Не стоит бездумно добавлять индексы “на все”. Включите логирование медленных запросов, анализируйте и добавляйте индексы.

  5. Не забывать удалять неиспользуемые индексы, так как каждый индекс увеличивает время изменения данных. Если вы делаете много изменений в данных, можно временно отключить индексы, провести пакетную обработку и включить индексы обратно. Проверьте, так может быть быстрее.

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

  7. Свойства, по которым не выполняется фильтрация, объединяйте и храните в сериализованном виде. Кешируйте при выводе.

  8. При создании свойста типа “Строка” в mysql таблице создается поле типа “TEXT”, поэтому при поиске или сортировке по этому свойству необходимо вручную изменять тип поля на varchar и добавить индекс.

  9. При большом объеме данных умный фильтр будет работать только с фасетным индексом. Включайте фасетный поиск для умного и для обычного фильтра.

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

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

Источник: Как делать highload на Битриксе. И надо ли