Pull to refresh

Отладка производительности и ускорение сайтов на Битрикс

Как увеличить скорость в 10 раз и обслуживать 300 000 посетителей в месяц на дешевом VDS


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

И так, проект пришел к нам на обслуживание с рядом проблем, одна из которых — страницы каталога сайта открывались в среднем около 5 секунд, а страницы производителей — около 20 секунд.

Как следствие, падала конверсия, Яндекс периодически «не видел» страницы и даже взаимодействовать с сайтом с целью решения каких-то задач, было проблемно.

Как отлаживать скорость в битрикс по шагам



Включаем монитор производительности на час.

Смотрим на самые долго открывающиеся страницы (в магазине это обычно каталог)

В нашем случае еще страница бренда и карточка товаров
/brands/detail.php — 24 секунды
/catalog/index.php — 5.8 секунд

image

На фото эти же страницы после отладки.
Открываем каталог.
Включаем отладку, смотрим запросы

Почему вообще может тормозить каталог в Битриксе?


Три базовые проблемы


Первая — огромные SQL запросы с 5-6 JOIN-ами.

image

Происходит это из-за того, что база сайта подстраивается под разные виды контента

  1. таблица для товаров
  2. для цен
  3. для складов
  4. для свойств
  5. И еще одна для значений свойств
  6. для языков
  7. для прав доступа

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

По-этому нет смысла ругать CMS, надо правильно с ней работать.

Например, этот огромный запрос будет выполняться почти мгновенно, если итоговая выборка небольшая (несколько тысяч товаров).

И он же будет очень долгим, если в выборке полмиллиона товаров. Решение?

Перестроить архитектуру сайта так, чтобы нигде не выводилось больше тысячи товаров единым списком (нужны включенные фильтры или разделы). Это сократит запрос до приемлемых 0.05 — 0.1 секунд.

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

image

Вторая — sql запросы, вложенные в php-цикл. Это проблема уже на стороне разработчика, который вместо того, чтобы нормально настроить компонент на извлечение нужных данных, «дергает» их внутри каждого товара отдельным запросом.

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

image

Здесь же найден еще один интересный модуль. Его дописали предыдущие разработчики для того, чтобы расставлять META-теги к поддоменам сайта. Для каждого города присутствия магазина есть свой поддомен для продвижения по конкретному городу. МОдуль работает на highload-инфоблоках Битрикс. В них по умолчанию не создаются mysql-индексы. Нужно изучить запросы и создать индексы самостоятельно. Как итог, исключен еще один «тяжеловесный» SQL-запрос.

image

Теперь меряем производительность заново. Среднее время формирования страницы каталога теперь 0,2-0,3 секунды.

Вторая нагруженная страница — это страница бренда


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

Плюс также включаем кеширование при установленном фильтре.

Измеряем производительность заново. Среднее время формирования страницы каталога теперь 0,2-0,4 секунды. Сократилось более чем в 100 раз!

image

Детальная карточка товара


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

Там же — отключаем выборку свойств, не использующихся в блоке «просмотренные товары». И отвоевываем еще треть секунды.

image

Немного радости для Pagespeed


Несмотря на название, именно скорость он как раз не меряет. Это своего рода чек-лист на скорость отображения в браузере уже сгенерированной страницы. Однако же кое-что из него все же стоит сделать.

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

image

Скорость вырастает вдвое — в 33 до 62 пунктов. Это не очень много, но для синтетического теста, прямо не влияющего на юзабилити — более чем достаточно.

image

Промежуточные итоги


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

image

А вот теперь — композитный кеш


Теперь, отладив производительность основных компонентов сайта, можно переходить к композитному кешированию.

В двух словах, он делает HTML-копию страницы, а в нее уже «Догружает» изменяющиеся детали (вроде логина пользователя).

С включенным композитным кешированием, страница отдается сервером за 0,03 секунды. И соответственно, отрисовывается на клиентском браузере примерно за 0,5 секунды.

image

А в завершение чек-лист по отладке скорости Битрикс

  • Настройки в мониторе производительности соответствуют рекомендуемым
  • Все компоненты настроены на кеширование
  • SQL-запросы не вызываются в циклах
  • Страница формируется с функцией «Очистить кеш» не более чем 200 SQL-запросами
  • Компоненты работают только со свойствами, которые им нужны
  • Проверка прав доступа отключена там, где не нужна
  • Если на сайте много скидок, сайт рассчитывает их только там, где нужно
  • Кеширование фильтров включено
  • При кешировании учитывается периодичность обновления
  • Настроен композитный сайт
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.
Change theme settings