С чего начинать?
Поиск решений необходимо начинать с технического аудита. Он включает в себя:
- Анализ серверов и их архитектуры
- Стандартные тесты 1С-Битрикс
- Анализ кода и программной архитектуры
- Тесты и проверку фронтенда
- Нагрузочное тестирование
- Функциональные тесты
Таким образом можно выявить причины низкой производительности сайта и составить детализированный и обоснованный план доработок и внедрений.
10 причин низкой производительности
Чаще всего проблемы кроются не в Битриксе, а в низком уровне компетенций подрядчика, который разрабатывал сайт.
1. Ошибки при работе с платформой
Чаще всего встречаются ошибки в работе типового функционала из-за модификаций в ядре 1С-Битрикс.
Еще одна проблема — создание самописных решений без особой необходимости вместо использования штатных компонентов Битрикса. Это вызывает проблемы при масштабировании функционала, обновлении CMS и развитии проекта.
2. Ошибки бэкенд-разработки на PHP и Bitrix API
Как правило, это лишние файлы, служебные скрипты в открытом доступе, отсутствие защиты при обращении к GET- и POST-параметрам.
3. SQL-запросы в файлах страниц, шаблонах и циклах
Ошибки логики, запросы к БД в цикле, постоянные повторы ошибок и, как следствие, высокая нагрузка на сайт и замедление его работы.
4. Кеширование компонентов отсутствует или отключено
В режиме отладки выводится сообщение о нулевом размере кеша, в результате чего — высокие нагрузки и замедление работы.
5. Ошибки верстки
Сайт загружается, но интерфейс не работает несколько секунд — в итоге пользователь видит сайт искаженным и испытывает трудности.
6. Проблемы с изображениями
Тяжелые и неоптимизированные изображения низкого качества, устаревшего формата и в неэффективной кодировке.
7. Некорректная работа скриптов
Например, сами скрипты подключаются с внешних серверов, которые географически удалены от сервера сайта.
8. Сервер и его окружение не настроены
При повышении посещаемости сайт замедляется или падает, и ресурс теряет возможных клиентов.
9. Агенты выполняются на хитах
Служебные процедуры, которые запускаются редко, но занимают много времени, например регулярная выгрузка номенклатуры на торговые площадки.
10. Не удалены неиспользуемые модули
Чем больше в системе модулей, тем дольше загружается любая страница и запускается инициализация ядра платформы.
Вывод: попытки сэкономить на этапе разработки всегда выливаются в дополнительные расходы на этапе техподдержки. Экономия получается мнимой: клиент тратит те же средства, но теряет еще и время.
Варианты решений
Перенос сессий и кеша в быстрое хранилище
Для повышения производительности проекта можно ускорить процесс отдачи кеша за счет использования сторонних средств.
Например, таких как Redis — это хранилище данных, которое хранит БД в оперативной памяти, за счет чего сайт получает возможность запрашивать данные максимально быстро. Скорость отдачи кеша превосходит стандартный MySQL в десятки раз.
Внедрение композитного кеша
В Битриксе есть собственный инструмент для ускорения отдачи кеша — технология «Композитный сайт». Контент страницы разделяется на статическую и динамическую составляющие. При первом визите сервер генерирует кешированную версию HTML-кода, а браузер запоминает скрипты, CSS-таблицы и графику.
При повторном открытии пользователем той же страницы сервер отдает версию из кеша, а параллельно подгружает графику и информацию, которая изменилась с момента кеширования. Так скорость загрузки вырастает в несколько раз.
Внедрение технологий Elastic
Использование Elasticsearch для интернет-магазинов на 1С-Битрикс позволяет сократить загрузку списка товаров из каталога при поиске и фильтрации.
Инструмент актуален для проектов с каталогами, где более 3000 товаров и у каждого много свойств. В таких случаях список товаров может загружаться с большой задержкой, сортировка по фильтрам — тормозить работу сайта, а изображения к товарам — загружаться не сразу.
После внедрения технологий от Elastic скорость работы в каталоге увеличивается в несколько раз.
Рефакторинг кода
Переработка бэкенда позволяет оптимизировать код. Для этого необходимо удалить костыли, текущие и потенциальные баги, привести код к единому стандарту, исправить ошибки проектирования и неоптимальную структуру.
Рассмотрим на примере.
Кейс №1. Сайт ювелирного завода имел проблемы с производительностью. Чтобы выяснить причины, мы провели технический аудит и выявили:
- Низкое качество программной реализации
- Несоблюдение стандартов разработки на 1С-Битрикс
- Множество источников скрытых ошибок
- Уязвимости для безопасности сайта
- Места с повышенной нагрузкой
- Легаси от нескольких подрядчиков с различными стилями написания кода и отсутствием единой концепции
Устранив большинство проблем и проведя рефакторинг, мы полностью решили вопросы со скоростью работы сайта.
Оптимизация серверной архитектуры
В ряде случаев низкая производительность сайта обусловлена не его возможностями, а обилием запросов. Например, в стандартном режиме сайт может работать корректно, но при резком скачке трафика или атаке ботов он начнет отказывать, потому что не рассчитан на такие нагрузки.
Кейс №2. Сайт производителя сантехники столкнулся с нашествием ботов, спам-атаками и DDoS.
Проблему надо было решать как можно быстрее, поэтому мы создали отдельный сервер с балансировщиком трафика, чтобы отправлять на него зловредных и бесполезных ботов. Таким запросам мы стали отдавать на скачивание упрощенную версию сайта без каталога, карточек товаров и возможности оформления заказов.
Всего задействовали четыре сервера:
- Балансировщик, который фильтрует и распределяет трафик
- Основной веб-сервер, который обслуживает только живых пользователей
- Веб-сервер для обслуживания запросов от поисковых и других ботов
- Сервер БД сайта, на котором расположена мастер-база сайта
Оптимизация архитектуры хранения данных о товарах в каталоге
Когда каталог насчитывает десятки тысяч позиций, а каждый товар может иметь несколько десятков свойств, описанных выше мер может быть недостаточно. Причина низкой производительности может крыться в архитектуре хранения данных.
Кейс №3. На сайте поставщика лабораторного оборудования был огромный каталог и проблемы с производительностью.
Мы провели рефакторинг кода, запустили комплексные компоненты и добавили фильтр в каталоге. Но при заведении новых свойств часть товаров становилась неактивной, а админка просто зависала.
Причина крылась в инфоблоках 2.0, которые были запущены Битриксом для ускорения работы небольших интернет-магазинов, где в каталоге меньше 50 тысяч товаров, а свойств не больше 300.
На проекте свойств товаров было больше тысячи, а в дальнейшем могло вырасти. Поэтому мы перевели страницы каталога на инфоблоки 1.0, которые отличаются от версии 2.0 способом записи и больше подходят для проектов с большим количеством товаров и свойств.
Так мы решили проблему и заложили значительный резерв для производительности.
Переход на микросервисную архитектуру
Современные высоконагруженные проекты ecom работают на микросервисной архитектуре. Ее ключевое отличие от обычной монолитной архитектуры в том, что проект реализуется на микросервисах, которые работают практически независимо, имеют свою БД, а иногда используют собственный стек технологий.
При этом внедрение не требует радикальных переработок: проект можно постепенно переводить на микросервисы до тех пор, пока он полностью не станет композитным.
Заключение
Поиск решений необходимо начинать с технического аудита. При качественной разработке большинство проблем и рисков нивелируются. А попытки сэкономить на этапе разработки всегда выливаются в дополнительные расходы на техподдержку — клиент тратит те же средства, но теряет еще и время.
