После весны 2020 года слово “тестирование” приобрело некоторые неожиданные значения и неоднозначные коннотации — пожалуй, везде, кроме IT. В нашей сфере без него никуда — и так было всегда.
Видов тестирования ПО — множество: модульное, функциональное, А/В-тестирование, интеграционное, нагрузочное и т д. И на наш взгляд, как раз последнее является как самым важным, так и наиболее сложным. Ведь если ошибки, которые могут быть выявлены с помощью A/B-тестов, модульных, функциональных и интеграционных тестов, проявляются практически сразу после “выкатки” новой версии приложения, то проблемы, на выявление которых нацелено нагрузочное тестирование, — “спящие”. И обнаруживаются они только тогда, когда на новую версию вашего сайта или приложения придет реальный пользовательский трафик, с которым не справится “софтверная” часть проекта (база данных, application-сервер) или “железно-инфраструктурная” (нехватка оперативной памяти в кластере, большая нагрузка на дисковую подсистему при операциях чтения-записи).
В этой статье расскажем и покажем, как мы проводить, кажется, эталонное нагрузочное тестирование — в плане полноты покрытия и полноты же получаемого в итоге отчёта. Наши наработки вполне воспроизводимы, так что вы можете воспользоваться ими для улучшения работы собственного проекта.
Что? Где? Когда?
Когда необходимо:
нужна оценка текущего лимита производительности проекта (например, перед какими-то промо-акциями, рассылками, “черной пятницей” и т д) — чтобы оценить объём временного наращивания мощности и изменения в конфигурации проекта на период акции;
вы ищете пути повышения производительности текущей архитектуры/инфраструктуры (поиск проблемных мест / “бутылочного горлышка”) на постоянной основе;
нужно проверить новый проект перед запуском в продакшн или новую инфраструктуру после переезда.
Что включено:
аудит текущей инфраструктуры,
составление сценариев нагрузочного тестирования и выбор инструментов для его проведения,
проведение нагрузочного тестирование,
составление отчета о результатах с рекомендациями по решению выявленных проблем.
Где смотреть:
технологический стек — с помощью каких инструментов, ЯП, фреймворков работает проект: это может быть как типичный монолитный веб-сайт на LAMP/LEMP-стеке, так и микросервисный проект, состоящий из 30 сервисов, написанных на различных ЯП (typescript, golang, python…); используется ли какое-либо дополнительное ПО (системы кэширования, системы полнотекстового поиска и т.д.)
рабочие мощности — это железные сервера или облачные ВМ с подключенным автомасштабированием, managed кластер Kubernetes и т.д.
хранение данных (как БД, так и загружаемые пользовательские файлы) — используется ли on-premise или managed база данных, настроена ли репликация (запись в мастер / чтение со слэйва) и т д. Где хранятся загружаемые пользовательские данные — локальный диск, s3-хранилище и т.д.
взаимодействие компонентов проекта между собой — как они связаны, какие подсистемы используются и в каком порядке обрабатывают входящий пользовательский запрос; если проект построен на микросервисной архитектуре — как сервисы общаются между собой; существуют ли какие-либо внешние зависимости (API платежного шлюза, сервис для email-рассылок), и если да — как осуществляется коммуникация с этими сервисами.
вспомогательные компоненты — настроены ли у проекта мониторинг, система сбора логов и трейсов, которые могут быть полезны в процессе нагрузочного тестирования для получения дополнительных данных и инсайтов.
Аудит инфраструктуры помогает лучше понять логику работы проекта, а также сразу найти возможные узкие места, например, синхронный запрос к платежной системе во время оплаты заказа в интернет магазине; отсутствие системы кеширования для статичного контента (страница на новостном портале, включая дополнительный раздел “по этой же теме”). А данные из имеющихся систем мониторинга и сбора логов используем для улучшения сценариев тестирования и поиска узких мест.
Сценарии тестирования и выбор инструментов
Сценарии
В идеальном мире сценарии тестирования должны полностью имитировать пользовательское поведение на сайте — переходы по страницам, процедуры авторизации и аутентификации, сброс и смену пароля, добавление/удаление товаров в корзину, оформление заказа и т д.
Когда мы проводили нагрузочное тестирование для “Тотального диктанта”, в сценариях описывали следующие процессы:
аутентификация пользователя на сайте,
заполнение и промежуточное сохранение диктанта,
отправка диктанта на проверку.
Самые частые в нашей практики варианты формирования конечного сценария таковы:
заказчик сам формулирует набор сценариев, которые необходимо реализовать — самый идеальный и простой путь :-)
сценарии формируются совместно нашими специалистами с командой заказчика — например, если тестирование запланировано перед промо-акцией или регулярной сезонной нагрузкой, и набор критериев более-менее понятен.
заказчик хочет тестирование, но не может точно сформулировать критерии — в этом случае мы анализируем access-логи веб-сервера, например, за последний месяц, отбрасываем из них запросы к статическим файлам и формируем из них набор сценариев для тестирования, тем самым покрывая большую часть поведения пользователей на сайте.
Инструменты
Наши ТОП-2 — это Яндекс.Танк и Apache JMeter.
Яндекс.Танк — инструмент для проведения нагрузочного тестирования, разрабатываемый в компании Яндекс и распространяемый по лицензии LGPL. В основе инструмента лежит высокопроизводительный асинхронный генератор нагрузки phantom: он был переделан из одноименного веб-сервера, который «научили» работать в режиме клиента. При помощи phantom можно генерировать десятки и сотни тысяч HTTP-запросов в секунду (http-requests per second, http-rps).
На наш взгляд, довольно простой и легкий инструмент для “простых” нагрузочных тестирований: переходы по страницам, без авторизации и прочих дополнительных условий. “Из коробки” позволяет строить графики по результатам нагрузки и предоставлять полноценный отчет о тестировании.
Пример конфигурационного файла для "Яндекс.Танка":
# cat load.yaml
phantom:
address: xx.yyy.zzz.qqq:443
ssl: true
load_profile:
load_type: rps # schedule load by defining requests per second
schedule: const(350, 1000s)
header_http: '1.1'
headers:
- "Host: test.ru"
- "Connection: close"
- "Accept-Encoding: gzip, deflate"
- "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36"
ammofile: ./test.log_clear
ammo_type: uri
package: yandextank.plugins.Phantom
telegraf:
enabled: false # let's disable telegraf monitoring for this time
overload:
package: yandextank.plugins.DataUploader
enabled: true
token_file: ./token.txt
api_address: https://overload.yandex.net/
job_name: test.ru
Пример файла со списком url для конфигурационного файла из примера выше:
# head -n 10 test.log_clear
/stat/word/collect/c9cdc1dc-884f-45d3-b5d2-15e35cd1c7e8
/posts/78053
/books/10_non_fiction_knig_ot_noama_khomskogo-912394.xhtml
/world/samye_opasnye_v_mire_morya_8_faktov_o_piratakh_yugo_vostochnoy_azii-1161411.xhtml
/posts/92382
/posts/72761
/signin
/comments/58717
/comments/92382
/comments/92374
Интересные статьи
Интересные статьи
