Как провести нагрузочное тестирование интернет-магазина на Битрикс

В статье разберемся:

• что такое нагрузочное тестирование;
• когда, как и зачем проводить нагрузочное тестирование на Битрикс — на примере кейса интернет-магазина верхней одежды и аксессуаров;
• что из себя представляют стресс-тест сайта и инструмент нагрузочного тестирования Яндекс Танк (Yandex Tank).

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

1. Зачем проводить нагрузочное тестирование сайта
2. Виды нагрузочного тестирования
3. Инструменты нагрузочного тестирования
4. Как провести нагрузочное тестирование сайта
5. Запуск и анализ результатов нагрузочного тестирования
6. Чем все закончилось для клиента

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

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

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

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

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

Существует две модели нагрузочного тестирования:

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

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

В качестве инструмента для нагрузочного тестирования мы обычно используем Яндекс Танк (Yandex Tank) — нагрузочный фреймворк для анализа производительности сайтов. В основе инструмента Яндекс Танк — система генерации нагрузки Phantom, позволяющая производить десятки и сотни тысяч HTTP-запросов в секунду.

Инструмент Яндекс Танк сохраняет результаты в текстовых журналах, а специальный модуль выводит их в консольный интерфейс в виде таблиц. Есть возможность направить результаты теста на сервис Overload для удобного анализа результатов. Также инструмент обеспечивает мониторинг ресурсов сервера по SSH-протоколу и автоматическую остановка теста при заданных условиях. В инструменте можно подключать модули для достижения необходимой функциональности.

К нам обратился крупный интернет-магазин верхней одежды и аксессуаров со следующей проблемой.

Клиенту другой разработчик собрал новый сайт. Чтобы проверить, какую нагрузку он выдерживает, направили часть трафика со старого сайта на новый. Сайт «лег». Перед клиентом встал вопрос — «чинить» новый сайт или «хоронить», и разработать ещё один на фреймворке.

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

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

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

Для прогрева кеша использовали статичную нагрузку. В качестве инструмента нагрузочного тестирования — Яндекс Танк с модулем Phantom. Phantom отличается высокой производительностью, но не позволяет генерировать POST-запросы — мы не можем проверить сценарии отправки отзывов, авторизации на сайте и добавления товаров в корзину. Поэтому мы оценивали количество запросов в секунду, которое может выдержать сайт, без анализа добавления товаров в корзину.

Конфигурация Web сервера:

• Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
• RAM: 64 Gb
• SSD: 500 Gb (RAID 1)

Конфигурация сервера БД:

• Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz
• RAM 188 Gb
• SSD NVME 1Тб (RAID 1)

Серверы работали на OS Debian 9.11

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

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

• 70% — страницы товаров;
• 20% — страницы категорий товаров;
• 5% — URL, содержащие фильтры;
• 5% — прочие страницы (главная, страницы блога, информационные страницы).

Были выставлены лимиты, при достижении любого из которых стресс-тест автоматически останавливается:

• time(3s,20s) — если среднее время ответа более 3 секунд в течение 20 секунд;
  
• http(5xx,100%,10s) — если в течение 10 секунд 100% обращений выдают 5xx ошибки;
  
• net(xx,100%,5s) — если в течение 5 секунд 100% получаем ошибки сети, такие как 104 — Connection reset by peer и 110 — Connection timed out.
  

Чтобы получить корректные значения, стресс-тест сайта нужно выполнять в несколько этапов.

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

RPS (request per second) — число запросов в секунду на страницы сайта, которые производили при нагрузочном тестировании. Показывает примерное количество запросов, после которого был прерван тест — либо из-за отсутствия ответа по сети, либо из-за ошибок в HTTP запросах.

Условия: запущен тест примерно на 1000 страниц, отсортированных по типам и по алфавиту. Кэш на сайте не сбрасывали.

Результат можно посмотреть здесь. RPS=256. В этот раз сайт также выдержал нагрузку, и нагрузка на сервер составила не более 30%. Нагрузка на базу данных была мизерной. LoadAverage не превышал трех. Тест прервался по причине сетевой недоступности из-за повышенной нагрузки на канал связи.

Условия: был сброшен кэш. Тест запущен по большому списку отсортированных страниц.

Результат можно посмотреть здесь. RPS=11.

При достижении примерно 11 запросов в секунду нагрузка на базу данных выросла до 100%.

Условия: тестирование сайта по прежнему списку при «прогретом» кэше.

Результат можно посмотреть здесь. RPS=250.

При тестировании сервер был загружен максимум на 30%. База данных тоже была загружена не более чем на 30%, а зачастую меньше. Тест прервался по причине сетевой недоступности из-за повышенной нагрузки на канал связи. На внешнем сетевом интерфейсе web-сервера сайта загрузка канала превысила 800 мегабит в секунду.

Условия: тестирование демо-сайта на чистом Битриксе при пустом кэше с базой на локальном сервере.

Результат можно посмотреть здесь. При RPS=168 нагрузка на процессор выросла до 100%.

Условия: Тестирование демо сайта с шаблоном готового решения Aspro Next, на котором базировался код тестируемого сайта при пустом кэше с базой на локальном сервере.

Результат: При RPS=128 нагрузка на процессор выросла до 100%.

Следом за нагрузочным тестированием мы провели глубокий технический аудит сайта. Сделали рефакторинг компонентов и исправили все выявленные в результате аудита проблемы. Сегодня сайт выдерживает до 60 тысяч посетителей в сутки.