Когда нужно проводить нагрузочное тестирование?

Что это? От чего страхует нагрузочное тестирование? Когда рекомендуется его проводить?

Нагрузочное тестирование (англ. — load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

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

Мы рекомендуем делать нагрузочное тестирование в следующих случаях:

• Вы запустили новый проект.

• Вы внедрили крупное изменение, которое существенно влияет на функционал (например, редизайн сайта, затрагивающий функционал).

• Вы планируете участвовать в крупных маркетинговых акциях, которые привлекут большой трафик на сайт (например, участие в черной пятнице, или пост на habr.com).

• Просто периодически (например, раз в год).

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

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

Только представьте себе ситуацию: запланировано важное событие.

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

Чтобы такого не произошло, нужно проводить стресс-тесты планово.

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

Скажем так: без инструментов автоматизации нагрузочных тестов, тестирование провести нереально.

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

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

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

Для одного из наших ключевых клиентов, компании Самсонайт, было решено провести нагрузочный тест перед одной из самых популярных распродаж года — «Черной пятнице». Она, как мы помним, стартовала 27 ноября 2019 года.

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

В данный момент на поддержке находится 4 бренда компании: Samsonite, American Tourister, Tumi, Lipault. У каждого из них отдельный интернет-магазин.

Буквально за месяц до распродажи закончился переезд проектов на новый сервер, работа сайтов на нем была отлажена, но нужно было срочно получить ответы на вопросы: какое количество одновременных посетителей теперь выдерживает каждый из них? Как сказались масштабные доработки проектов на их отказоустойчивости под нагрузкой?

Под 4 проекта завели 2 новых сервера, объединенных в кластер, с балансировщиком нагрузки.

Для стресс-теста использовали Яндекс.Танк.

Для создания сценария, взяли кусок access_log, немного отфильтровали его, добавили в него:

• Новые страницы с акцией и акционными товарами.

• Добавление товара в корзину.

• Процесс оформления заказа.

Проверили по данным Яндекс.Метрики нагрузку на прошлой «Черной пятнице».

Берём четверть от этой посещаемости и пускаем самый простой сценарий с равномерной нагрузкой в течение 10 минут для первого из сайтов (самого крупного – samsonite.ru).

И … тут нас ожидает epic fail. Загрузка CPU на обоих серверах – 100%, сайты еле открываются.

По оставшимся трем проектам ситуация схожая.

Увеличиваем нагрузку на 10% и получаем отказы в обслуживании с абсолютно разными ошибками (403, 404, 408).

Вердикт: тесты дальше проводить бесполезно, «Черную пятницу» мы не выдержим. Нужно что-то делать.

Времени оставалось очень мало.

Начинаем поиск узких мест. В целом, к серверному окружению претензий было мало.

Немного подкрутили параметры базы данных, отказались от использования кластера master-master (он существенно замедляет запросы на запись, а в интернет-магазине постоянно идут обмены с CRM и 1С, обновление цен и остатков).

Кеш проектов хранился в файлах на диске. Был поднят memceched, кэш перенесён в него.

По сайтам:

Собираем количество и скорость выполнения MySQL-запросов с каждого блока по-отдельности. На проектах используется 1C-Bitrix, в нём есть достаточно удобные инструменты для профилирования скорости серверной генерации проекта.

Из найденных проблем:

• При генерации меню – непозволительно много запросов к БД.

Оптимизируем.

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

• В блоке фильтрации товара была странная проблема: запросов к БД мало, скорость выполнения запросов небольшая, однако блок генерировался непростительно долго.

Используем XHProf, смотрим по таймерам. Находим очень интересный «косяк» с многократным обращением к файлу на диске (объемом почти 1 Мбайт).

Исправляем, все необходимые данные переносим в БД, тем самым снимаем нагрузку с дисков.

• Для экономии пропускной способности интернет-канала сервера, используем lazyload на всех картинках.

После оптимизации прогоняем повторный тест. Результат – отличный.

Запускаем ¼ нагрузки – сервер даже не замечает её.

Запускаем полную ожидаемую нагрузку – сервер также её не замечает, время генерации и загрузки страниц не изменилось.

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

Время загрузки сайта увеличивается. Сервер генерирует страницы до 1-2 секунд.

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

Отзыв клиента можно увидеть здесь — https://pixelplus.ru/studio/reviews/

«Уважаемый Анатолий Юрьевич, хочу поблагодарить вас и всю команду «Пиксель Плюс» за великолепную поддержку интернет-магазинов компании «Самсонайт» в ходе распродажи «Чёрная Пятница 2019».

Отдельно хотел бы отметить нашего менеджера Яковлеву Татьяну и ведущего программиста Гелейшева Павла за основной вклад в общий успех.

С огромным удовольствием продолжаем совместное эффективное развитие и достижение новых горизонтов.»

Над проектом работали:

• Старший SUP-менеджер «Пиксель Плюс» Яковлева Татьяна;
• SUP-специалист (Senior) «Пиксель Плюс» Гелейшев Павел.

Кейс подготовлен командой интернет-агентства «Пиксель Плюс»:

• редактором Кулик Валерией;
• маркетологом Станиогловым Вячеславом.