Ускорение высоко и средне нагруженных сайтов на Битрикс


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


В этом тексте я расскажу, почему они такие и что с этим делать.



Сначала теоретическая вводная. Каталог сайта на Битрикс — это модульный конструктор, который постоянно в процессе обмена с 1С, получает новые виды данный: файлы, свойства и их значения, типы цен и цены, склады и остатки по складам. Как результат, для извлечения этих данных нужны длинные запросы, сконструированные автоматически по большому числу таблиц. Обычно они достаточно быстрые, если не нарушать нескольких простых правил: извлекать только нужные свойства, использовать ID инфоблоков и не вкладывать SQL запросы в PHP-цикл. Стандартные правила, однако когда ими пренебрегают ради гибкости или скорости разработки, минимальная нагрузка завешивает сервер.




Наш пациент: сайт запчастей к бытовой технике с посещаемостью до полумиллиона уников в месяц.


Симптомы: страницы открываются в среднем 5-6 секунд. Иногда не открываются вовсе.


Сервер: стандартный VDS за 2000р/месяц



Интересный дополнительный симптом: часто не открывается даже статичная страница (например, картинка) с сервера. Почему так бывает? Потому что Web-сервер может одновременно обрабатывать ограниченное число «потоков» передачи данных. Остальные запросы становятся в очередь. Таким образом, если PHP-страница открывается достаточно долго, то несколько одновременных обращений пользователей «забивают» сервер и все остальные становятся в бесконечную очередь.



Что делаем:


Сначала нам нужно собрать самые нагруженные страницы.


Для этого запускаем монитор производительности на полчаса.


В отчете видим страницы


/brands/detail.php — среднее время открытия 24 секунды


/catalog/index.php — среднее время открытия — 5.8 секунд




На скрин-шоте эти же страницы после оптимизации :-)

В битриксе есть встроенный механизм отладки производительности страницы и SQL-запросов.


Включаем его и смотрим, что создает нагрузку.



Что находим


Модуль, подставляющий SEO заголовки по городам, формирует на каждой странице (кроме админских) длинный запрос выборки ключевых слов. Выборка происходит на основе кода инфоблока плюс кода элемента. Заменив код инфоблока на его ID, получаем ускорение выдачи примерно в 100 раз. Почему? Да потому что для IBLOCK_CODE не создан индекс в SQL таблице.



Что это значит?


Это значит, что база залезает в каждую ячейку и проводит там поиск.


А если есть индекс, то поиск проходит по скрытым данным в таблице, отсортированным внутри удобным образом. Примерно в 100-1000 раз быстрее.





Лезем чуть глубже


К каждому товару подтягиваются аналоги. Эти аналоги хранятся в обычной SQL-таблице и работают через XML_ID товара. Однако в поле с XML_ID не создан индекс.


Запросом CREATE_INDEX создаем его и вот — сайт стал еще чуть быстрее.



Из совсем простого


Товары выбираются по бренду при помощи компонента catalog.section со включенным фильтром. Значит, надо поставить параметр CACHE_FILTER = Y и компонент начнет сохранять данные, а не формировать их каждый раз.


Итог — время формирования страницы бренда сократилось с 24 секунд до 0.3 секунд — почти в 100 раз(!)




Теперь идем в каталог


Аналогично включаем CACHE_FILTER — получаем ускорение страницы.




Теперь к более сложному


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




В нашем случае страница ускорилась в среднем на 3 секунды






Там же на всех страницах — блок «просмотренные товары».




В нем извлекается ряд данных, не использующихся на выдаче в файле result_modifier.php


Корректируем. Отключаем выборку.


Отвоевали еще треть секунды.


Немного корректировок для Google Pagespeed


На самом деле, вопреки своему названию, этот инструмент не меряет никакую скорость. То есть он меряет много всего, но именно скорость — нет.


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


— включаем кеширование файлов


— включаем сжатие скриптов


— убираем через tinypng избыточность картинок в шаблоне и баннерах




Скорость вырастает с 33 до 62 для ПК и 74 на мобильном.



Время формирования страницы по отчетам в среднем 0.3 секунды


Визуально полная загрузка около секунды




Как итог


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



P.S. Чтобы быть в курсе новых публикаций, подписывайтесь на меня в Facebook.




К сожалению, не доступен сервер mySQL