Аудит — ИНТЕРВОЛГА наносит ответный удар

2016 был урожайным на технические аудиты сложных интернет-магазинов. Практически все обращения были связаны с медленной работой сайта. Это типичная проблема сайтов на 1С-Битрикс, которые активно дорабатываются несколькими командами или были сделаны криво, на скорую руку.

В ходе аудита мы проверяем:

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

  2. Исходный код проекта и взаимодействие с базой данных

  3. Работу сайта под нагрузкой


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

Несмотря на разнообразие проектов, особенности их реализации и архитектуры, проблемы у всех одинаковые. Мы составили рейтинг самых критичных и распространенных проблем, которые делают интернет-магазин медленным.

Недостаточные навыки программирования и знания 1С-Битрикс

У 1С-Битрикс есть свои правила разработки. В них описаны особенности работы системы и то, как нужно с ней работать. Практически во всех проблемных проектах, мы встречаем отступления от правил или их несоблюдение, которые приводят к ошибкам и проблемам производительности.

Распространенность: Очень высокая, встречается повсеместно

Признаки: SQL-запросы в файлах страниц, шаблонах, запросы в циклах

Критичность: Высокая

Последствия: ошибки логики, постоянные повторы ошибок, высокая нагрузка на ровном месте, медленная работа

Эта распространенная проблема возникает по двум причинам: плохо организованный процесс разработки и недостаточная квалификация разработчика.

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

Почему дорого сопровождать?

Задачи которые нужно просто “сделать” становятся задачами “разберись, придумай решение которое не сломает всё что есть и сделай”.

Почему падает скорость?

Несмотря на то, что Битрикс имеет встроенную систему кэширования, он кэширует не всё. По незнанию программист может разместить php-код работы с базой данных прямо в шаблоне сайта, это приведет к замедлению всех страниц.

Например, на всех страницах сайта нужно вывести меню, пункты которого соответствуют разделам в каталоге. Быстрое, но плохое решение – в шаблоне сайта вызвать CIBlockElement::GetList() и в цикле обернуть в верстку полученный результат.

Время решения задачи таким способом – 15 минут. Однако теперь на каждый хит будет отправляться запрос в базу данных. Битрикс не сможет его кэшировать и такой запрос будет создавать нагрузку. А если программист не передаст в параметры ID инфоблока, запрос будет выполняться еще дольше. Вроде мелочь, а на деле +0,1 сек. к времени генерации каждой страницы, на сервере с плохо настроенной базой данных. Правильное решение - использовать стандартный компонент bitrix:menu. Такое решение займет не намного больше времени ~30 минут, но не будет замедлять сайт.

Есть несколько способов обнаружить подобные проблемы: профилировать код с помощью XDebug или XHprof и проверять исходный код сайта вручную, читая код шаблонов, компонент и модулей.

Стоимость устранения этой проблемы сильно зависит от количества ошибок. В среднем, на интернет-магазин уходит 20-40 часов исправлений плохого стиля кодирования.

Отсутствует или отключено кэширование компонентов

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

Распространенность: Очень высокая, встречается повсеместно

Признаки: В режиме отладки выводится сообщение о нулевом размере кэша

Критичность: Очень высокая

Последствия: Медленная работа, высокая нагрузка

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



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

Иногда разработчики забывают реализовать поддержку кэширования в собственных компонентах или допускают грубые ошибки, которые мешают кэшировать данные, или не разобравшись с правилами работы кэширования, отключают его совсем.

Проблема обнаруживается стандартной проверкой Битрикс “монитор производительности”.

Включение кэширования стандартных компонент занимает пару минут. Устранение проблем в нестандартных или кастомизированных компонентах занимает от 4 до 8 часов. Однако, иногда исправление невозможно и приходится заново программировать компонент.

Ошибки верстки

Страница может загружаться долго не только из-за проблем в серверном коде (back-end). Быстро сгенерированная страница может содержать ошибки верстки: изображения не оптимального размера, подключение JS-файлов с медленных внешних серверов и т.д.

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

Распространенность: средняя

Признаки: Сайт загрузился, но интерфейс не работает несколько секунд

Критичность: Высокая

Последствия: Пользователь видит сайт искаженным, поисковые системы считают сайт плохим

Подобные ошибки мы находим с помощью webpagetest.org и developers.google.com/speed/pagespeed/insights/

webpagetest.org показывает как загружается страница в разных городах и странах и дает подробную статистику о том что тормозит процесс.

Google pagespeed insights сразу выводит список проблем на странице, которые нужно исправлять.

Если забыть об ошибках HTML, остальные проблемы можно разделить на 2 большие группы: Проблемы с картинками и проблемы со скриптами.

Проблемы с картинками

Неоптимизированные картинки неподходящего размера.

Наиболее распространена ошибка с неоптимальными картинками. Неоптимальная картинка – слишком большая или слишком маленькая для того места, где она выводится. Мало кто занимается оптимизацией фотографий перед загрузкой на сайт, а еще меньше знает, что это процесс можно автоматизировать или средствами Битрикс или установкой плагина к Nginx. Это решение позволяет отдать картинки нужного размера, сжатые без потери качества.

Проблемы со скриптами

Подключение скриптов с “далёких” внешних серверов.

Чтобы скачать файл браузер тратит время на поиск установку соединения с удаленным сервером и только потом начинает скачивать файл. Чем дальше сервер от клиента, тем дольше устанавливать соединение.


Если это JS-библиотека, которая используется повсеместно на сайте, то пока она не скачается, сайт работать не будет. Проблема усугубляется, если библиотека находится на сервере на другом континенте.

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

Посетитель сайта не может взаимодействовать со страницей, пока не будут загружен HTML-код.

Распространённой ошибкой является подключение десятков JS и CSS файлов в начале HTML-кода страницы. При таком подходе, браузер не начнёт рендеринг, пока не скачает весь JS и CSS.

В 1С-Битрикс есть настройки, которые позволяют не только перемещать JS  в конец страницы, но и объединять их.


Однако, эти функции работают, только при правильном подключение файлов:


В остальных случаях, галочка никак не повлияет на скорость загрузки страниц.

Объем работ по устранению проблем сильно зависит от количества обнаруженных ошибок. В среднем, проблемы решаются за 4-10 часов, однако, в нашей практике был случай, когда решение потребовало 40 часов работы front-end и back-end разработчиков.

Низкий уровень безопасности системы

Если вы не видите проблем безопасности, это не значит, что их нет. Мало кто проверяет свой сайт встроенным в Битрикс “сканером безопасности” после разработки или доработки сайта.


Распространенность: средняя

Признаки: внешние отсутствуют

Критичность: Высокая

Последствия: Злоумышленники и конкуренты могут получить доступ к сайту

Встроенный “сканер безопасности” позволяет обнаружить много разных проблем:

  1. Уязвимости вроде SQL-injection, Cross-Site Scripting и т.д., которые позволяют злоумышленнику получить доступ в админку

  2. Файлы сессий других проектов, которые позволят пользователю авторизоваться на одном из ваших сайтов и получить доступ к другому (в рамках одного хостинга).

  3. Отладочную информацию, которая выводится на страницах публичной части

  4. Служебные файлы, доступные по URL. К служебным файлам относятся скрипты для восстановления сайта из резервной копии. Такой скрипт может быть запущен злоумышленником и доставит массу неприятностей.

Это далеко не полный перечень проблем, которые мы находим в проектах. Однако, их устранение позволяет защитить сайт и бизнес.

Мы часто находим скрипты в корневой директории сайтов, которые позволяют авторизоваться на сайте с правами администратора. Если URL на эту страницу попадет в индекс поисковых систем, беды не миновать.

Объем работ по устранению проблемы редко превышает 4 часов.

Не настроен сервер

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

Распространенность: высокая

Признаки: сайт работает медленно

Критичность: Высокая

Последствия: Перегрузка сервера, потеря позиций в поисковых системах из-за простоя

Настройка веб-сервера напоминает задачу по расстановке касс в супермаркете.

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

Ширина — оперативная память сервера. Время обслуживания одного покупателя – и место, которое он занимает это процессорное время и память, которая расходуется на один запрос. Исходя из этих данных можно настроить максимальное количество процессов, ограничить количество подключений к базе данных и т.д. Это ускорит обработку очереди, которая образуется во время пиковых нагрузок.

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

ИНТЕРВОЛГА проводит нагрузочное тестирование проектов. Во время тестирования мы плавно увеличиваем количество одновременных запросов к серверу и наблюдаем за расходом ресурсов. Как только сервер перестает справляться с нагрузкой, он начинает выдавать ошибки  посетителям.


В ходе эксперимента мы получаем максимальный RPS – максимальное количество запросов с которым справляется сервер. Чтобы тестирование было честным и не мешало работе сайта, мы делаем его копию на своем стенде, а в качестве нагрузки даём наиболее частый сценарий работы пользователя. Например, посещение цепочки страниц Главная-раздел каталога-фильтрация товаров-открытие нескольких карточек-добавление товара в корзину-оформление заказа. Для тестов мы используем Яндекс.Танк и JMeter.

Объем работ по настройке сервера и проведению нагрузочного тестирования 16-40 часов.

Не настроено автоматическое резервное копирование

Люди делятся на тех кто делает резервные копии и тех, кто ещё не начал это делать.


Распространенность: высокая

Признаки: Последняя резервная копия создана более 1 недели назад

Критичность: Высокая

Последствия: Катастрофа

Недостаточно делать резервные копии, их нужно регулярно проверять. Непроверенная копия = отсутствие резервной копии.

Что можно копировать и как?

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

Резервная копия сайта

1С-Битрикс имеет встроенную систему резервного копирования. Пока ваш сайт меньше 5 Гб, она прекрасно справляется со своей задачей. При работающем CRON, задача по настройке автоматического резервного копирования занимает 15 минут. Созданные бэкапы будут автоматически загружаться в облако 1С-Битрикс.

Резервная копия сервера

Если сайт работает на выделенном сервере, или он больше 5Гб, или на том же сервере хранится корпоративная почта и что-то ещё, нужно создавать резервные копии всей файловой системы сервера.

Для автоматического резервного копирования и проверки копий, мы используем Bareos. Особенности его работы мы опишем в одной из следующих статей.


Стоимость настройки резервного копирования сервера и последующее администрирование 8000 руб./месяц. Услуга оказывается в рамках администрирования и круглосуточной поддержки сайтов на битрикс.

Выполнение агентов на хитах, а не CRON. Отправка почты по 1 письму на хит.

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

Признаки: Непостоянное время генерации страниц

Критичность: Средняя

Последствия: Медленная работа сайта

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

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

В битриксе есть 2 режима запуска агентов: на хитах и по CRON. Если агенты выполняются на хитах, то при каждом обращение пользователся к сайту, Битрикс будет проверять список служебных процедур и выполнять одну из них. Пока процедура не выполнится, пользователь не увидит страницу сайта.

Если процедура выполняется минуту, пользователь будет ждать минуту.  Альтернатива – использовать планировщик задач CRON, который устанавливается в операционную систему на сервере. CRON позволяет задать расписание и автоматически запускать агенты 1С-Битрикс на сайте.

Настройка занимает не более 30 минут.

Не удалены неиспользуемые модули

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

Признаки: Медленно загружаются пустые страницы

Критичность: Низкая

Последствия: Медленная работа сайта

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

Список модулей доступен в разделе Администрирование на странице Настройки->Модули.

Мы рекомендуем отключать неиспользуемые модули.

Заключение

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

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