Вступление

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

Однако в процессе длительного использования выявились недостатки, такие как отсутствие необходимой информации, ограниченные возможности для сравнения результатов, недостаточная гибкость настроек, субъективная оценка результатов в некоторых случаях, а также невозможность просмотреть детальные данные и графики по каждому нагружаемому методу. Помимо этого, с помощью сервиса удалось выявить некоторые аномалии в работе наших микросервисов. За время работы с load-testing-hub также были реализованы важные для нашей команды и компании фичи, каждая из которых проходила нагрузочное тестирование с использованием данного сервиса для анализа производительности.

Одной из таких фичей стал поиск по операциям в ленте операций в мобильном приложении банка. Контекст: необходимо было реализовать поиск по операциям, которых в системе насчитывается несколько сотен миллионов. Возможно, это не кажется критичным объемом, но на самом деле речь идет о гигантских данных размером свыше сотни гигабайт. Эти данные нужно было "засидить" в базу данных, подготовить нагрузочное окружение и провести тестирование.

С небольшими объемами данных (100–200 тыс. записей) работа обычно не вызывает проблем. Но когда речь заходит о сотнях миллионов или нескольких миллиардах записей, становится критически важным выбирать максимально оптимальные алгоритмы генерации данных и их вставки в базу. Анализ результатов нагрузочного тестирования поиска проводился через load-testing-hub, что позволило получить массу полезной информации, выявить узкие места и, в конечном итоге, выпустить фичу с максимальной оптимизацией. При этом была проделана огромная работа как над самой фичей, так и над улучшением load-testing-hub, о чем я расскажу в этой статье.

Объем изменений в load-testing-hub был настолько значительным, что проще рассказать о сервисе заново, чем сравнивать его с версией, описанной в предыдущей статье. Поэтому я начну с самого начала, делая отсылки к MVP-версии лишь в ключевых местах.

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

Сервисы

Базовой сущностью в сервисе load-testing-hub являются services — то есть сервисы, которые подвергаются нагрузочному тестированию. В нашем случае используется протокол gRPC, в рамках которого один физический сервис может содержать несколько логических. Например, есть сервис mobile-gateway-service, внутри которого находятся логические сервисы account-service, cards-service и operations-service. Мобильное приложение обращается к хосту mobile-gateway-service, используя gRPC-контракты логических сервисов. В данном случае сущность services в load-testing-hub представляет собой именно физический сервис mobile-gateway-service.

В случае с HTTP можно встретить похожую архитектуру. Например, есть web-app-gateway с собственным хостом, но здесь отсутствуют контракты логических сервисов. Вместо этого логика сервисов (account-service, cards-service, operations-service) скрыта "под капотом" web-app-gateway, а доступ предоставляется через REST API. В этом случае сущность services в load-testing-hub также будет представлять физический сервис web-app-gateway.

Изменения по сравнению с MVP

В новой версии load-testing-hub появился функционал управления сервисами через UI, а все сервисы были вынесены на отдельную страницу.

Каждый элемент списка содержит:

Базовую информацию о сервисе.
Небольшую статистику: количество сценариев для данного сервиса и количество нагрузочных результатов.

Создание и редактирование сервисов теперь реализовано через модальные окна:

Причины изменений

Устранение конфликтов при работе с несколькими вкладками
Ранее выбор сервиса происходил через модальное окно, что приводило к проблемам при работе с несколькими вкладками. Данные о выбранном сервисе хранились в localStorage, который привязан к домену. В результате, если в одной вкладке выбрать один сервис, а в другой — другой, после перезагрузки первой вкладки данные из второй перезаписывали данные первой.
Теперь идентификатор сервиса фиксируется в URI, например:
/services/199/results.
Это не только устраняет проблемы с несколькими вкладками, но и позволяет удобнее конструировать ссылки на различные части приложения.
Такое решение кажется очевидным, но на этапе разработки MVP зачастую выбираются минимальные рабочие подходы с мыслью "лишь бы работало". Позже приходится перерабатывать многое, чтобы учесть реальный масштаб использования.
Масштабируемость
Ранее создание сервисов происходило вручную через базу данных, что было неудобным и нецелевым решением. Например, если в компании множество команд, каждая из которых использует load-testing-hub, важно, чтобы каждая команда могла самостоятельно управлять своими сервисами и результатами нагрузочных тестов.
Теперь каждая команда может работать независимо, без необходимости "лезть под капот" и вносить изменения в базу данных.

В будущем планируется расширять использование load-testing-hub на другие команды и сервисы. В этом контексте редактирование сущностей напрямую через базу данных становится недопустимым.

Результаты

В данном разделе отображается список запусков нагрузочного тестирования (НТ).

Информация на карточке результата

Каждая карточка содержит следующую информацию:

Заголовок — идентификатор запуска, название сервиса, для которого проводилось тестирование, и название нагрузочного сценария.
Средний RPS (Requests Per Second) для данного запуска.
Графическая шкала — отображает общее количество успешных запросов и количество запросов с ошибками.
Количество виртуальных пользователей, использованных в тестировании.
Время запуска — отображает начальное и конечное время выполнения теста, а также его продолжительность (например, 2m59s).
Блок тегов:
- Версия нагружаемого сервиса (если была предоставлена).
- Теги сравнения текущего результата с предыдущим и средними значениями.
- Версия сценария и его теги (например, LATEST, EXPERIMENT, LEGACY).

Логика сравнения результатов

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

Если сценарий выбран, сравнение производится среди запусков только этого сценария.

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

Дополнительные функции

Иконка быстрого перехода — при нажатии на нее открывается джоба, в которой был запущен данный нагрузочный тест. Это удобно, если необходимо быстро проанализировать, что пошло не так.
Load tests job URL
Меню управления нагрузочным запуском, включающее:
- Ссылки на пайплайны и джобы тестов.
- Просмотр деталей сценария.
- Возможность оставить комментарий к результату.
- Удаление некорректного результата.

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

Изменения в сравнении результатов

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

Ранее показатели {percent}% better/worse than average/previous рассчитывались предельно просто: сравнение шло исключительно по Requests Per Second (RPS). Такой подход был примитивным и недостаточно информативным. Он не позволял гибко выбирать метрики для анализа, а также не учитывал приоритеты различных сервисов.

Например:

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

MVP-версия не позволяла настраивать такие приоритеты, а нам этого очень хотелось. Поэтому функционал сравнения был полностью переработан.

Теперь:

Сравнение выполняется по всем метрикам одновременно.
У каждой метрики есть свой вес.
Учитывается контекст метрики.

Новая формула выглядит так:

$P_{\text{total}} = \sum_{i=1}^n w_i \cdot p_i$

Где:

$P_{\text{total}}$ — итоговый процент.
— количество метрик.
— вес -й метрики (доля от 1, например, 0.2, 0.3 и т.д.). Важно, сумма весов не может быть больше 1
— процент -й метрики (рассчитывается как разница между фактическим и ожидаемым значением, в процентах).

Пример: Если у нас есть три метрики:

Метрика number of requests: $w_1=0.4,p_1=50\%$
Метрика requests per second: $w_2=0.4,p_2=−20\%$
Метрика average response time (ms): $w_3=0.2,p_3=10\%$

Тогда итоговый процент:

$P_{\text{total}} = (0.4 \cdot 50\%) + (0.4 \cdot -20\%) + (0.2 \cdot 10\%) = 14\%$

Теперь у нас появилась возможность гибко настраивать веса метрик.

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

Это глобальное изменение, которое значительно расширяет возможности аналитики нагрузочного тестирования (НТ). Разные сервисы имеют разные приоритетные показатели, и теперь мы можем учитывать это при анализе. Подробнее о настройке весов расскажу в разделе "Settings".

Контекст метрик

Я также упоминал контекст метрик. Давайте разберем, что это значит.

Некоторые метрики чем выше, тем лучше. Например, Requests Per Second (RPS):

RPS = 100 лучше, чем RPS = 37, так как сервис обрабатывает больше запросов.

Другие метрики чем выше, тем хуже. Например, Max Response Time (максимальное время ответа):

700 ms хуже, чем 100 ms, потому что более долгий отклик негативно влияет на UX.

Таким образом, каждая метрика требует индивидуального подхода к сравнению. В новой версии load-testing-hub это учтено: у каждой метрики есть свой контекст, который автоматически учитывается при расчетах.

Пояснение к расчетам (Explanation)

Хотя вычисление процентного сравнения с учетом весов и контекста несложное, важно понимать, какие метрики участвуют в расчете.

Чтобы не держать расчеты это в голове, добавилась опция "Explanation".

Если нажать на лейбл сравнения, откроется тултип.
В нем будет подробно расписано, как именно рассчитан процент.
Эта возможность доступна для всех сравнений.

Дополнительные улучшения

Фильтрация результатов
Теперь можно фильтровать результаты по дате и времени начала/окончания НТ, а также по версии сервиса.
Results filters
Пагинация результатов
На странице с результатами добавлена пагинация, так как количество тестов может быть очень большим, особенно если они запускаются регулярно или автоматически по событиям. Например, для одного сервиса может накапливаться 200-300 запусков в среднем.
Results pagination

Детали результата

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

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

Number of users — количество виртуальных пользователей.
Number of requests — общее количество отправленных запросов.
Requests per second (RPS) — среднее количество запросов в секунду.
Number of failures — общее количество запросов, завершившихся с ошибкой.
Failures per second — среднее количество ошибочных запросов в секунду.
Max response time (ms) — максимальное время ответа (в миллисекундах) среди всех нагружаемых методов.Например, если тестировались три метода:
- GetUser → max response time = 10 ms
- GetUsers → max response time = 33 ms
- GetAccount → max response time = 57 ms
  
  Тогда итоговый Max response time = 57 ms.
Min response time (ms) — минимальное время ответа среди всех нагружаемых методов (по аналогии с Max response time, но вычисляется минимальное значение).
Median response time (ms) — медианное время ответа в миллисекундах.
Average response time (ms) — среднее время ответа среди всех нагружаемых методов.
Перцентили (50%-ile, 60%-ile, 70%-ile, 80%-ile, 90%-ile, 95%-ile, 99%-ile, 100%-ile) (ms) — распределение времени ответа по персентилям.

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

Комментарии к результату
К каждому запуску нагрузочного тестирования можно оставлять комментарии в произвольной форме. Эта функция особенно полезна при проведении экспериментов, например, при изменении ресурсов подов. В комментариях можно указать, на каком именно окружении выполнялся тест.
Set load test result comment
Просмотр деталей сценария
Можно открыть подробную информацию о сценарии, по которому был запущен нагрузочный тест.
Scenario details
Сравнение результатов
Доступен инструмент для сравнения текущего результата с другими запусками, сценариями или средними значениями. Подробнее об этом в разделе "Сравнения".
Comparison of result
Просмотр дашбордов Grafana и Kibana
Есть возможность открыть дашборды в Grafana и Kibana, но эти опции требуют предварительной настройки. Для их работы необходимо указать ссылки на инстансы Grafana и Kibana в конфигурации сервера, а также выполнить настройки на странице "Интеграции".
Integrations
Ссылки на связанные результаты
Здесь доступны все ссылки, которые отображались на карточке результата НТ, но также добавлена возможность перейти к предыдущему результату. При нажатии на эту опцию откроется страница с предыдущим запуском нагрузочного тестирования.
Result URLs

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

Функционал таблицы Statistics of methods

Сортировка
В таблице доступна сортировка по каждому столбцу, что упрощает анализ данных. Этот функционал реализован практически во всех таблицах системы.
Настройка отображаемых колонок
В правом верхнем углу виджета Statistics of methods (а также на других подобных виджетах) находится кнопка с иконкой шестеренки. Нажав на неё, можно выбрать, какие колонки таблицы отображать. Это особенно удобно, если необходимо сфокусироваться на определенных метриках и скрыть остальные для лучшего восприятия.
- Выбранные настройки автоматически сохраняются, и после перезагрузки страницы таблица останется в том же виде.
- В MVP-версии данной опции не было, и приходилось прокручивать таблицу, чтобы найти 2-3 ключевые метрики.

Под таблицей Statistics of methods расположена аналогичная таблица, но с распределением значений по персентилям.

Детализация данных по каждому методу

Рядом с каждым методом в таблице находится кнопка с иконкой графика. При нажатии на нее открывается модальное окно с подробной информацией по методу:

Вся информация из строки таблицы представлена в удобном виджете.
Внутри модального окна также отображаются различные графики:
- RPS,
- Время ответа,
- Количество запросов,
- Ошибки и т. д.

Этот функционал особенно полезен при анализе проблем с производительностью:

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

Method results details response times chart

Виджет с ошибками

Если в процессе тестирования возникли ошибки, они отображаются в отдельном виджете.

Графики с агрегированными данными

Далее идут несколько графиков, отображающих динамику ключевых показателей:

Total requests per second — изменение общего количества запросов в секунду по всем методам (включая количество ошибок).
Total number of requests — динамика общего количества запросов по всем методам (включая ошибки).
Response times (ms) — динамика времени ответа с несколькими метриками:
- min response time,
- max response time,
- average response time,
- median response time.
Number of users — изменение количества виртуальных пользователей во времени.

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

Если просуммировать/усреднить значения из результатов отдельных методов, получатся именно те графики, которые приведены в деталях результата.

Настройки отображаемых метрик на графиках

В правом верхнем углу каждого графика находится кнопка шестеренки, открывающая меню настройки отображаемых метрик.

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

Ранее в MVP-версии этого функционала не было, что создавало неудобства. Например:

Если одна метрика имела очень большие значения, а другая была значительно меньше, то их было сложно анализировать на одном графике.
Особенно это проявлялось при анализе ошибок:
- Если ошибок было мало, то график выглядел "плоским", и их динамику можно было увидеть только по отдельным точкам.

Zoom и таймлайн

Под каждым графиком расположена шкала timeline, позволяющая делать "zoom" и выделять конкретный временной интервал для детального анализа.

В MVP-версии этой опции не было.
Сейчас слайдер zoom добавлен практически на все графики.

Виджет распределения нагрузки по методам

Самый последний виджет на странице отображает распределение нагрузки по методам.

Этот виджет остался без изменений с MVP-версии.

Сравнения

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

1. Сравнение одного результата с несколькими другими

Позволяет анализировать разницу между несколькими тестовыми запусками. Например, можно сравнить результат A с результатами B, C и D, чтобы выявить изменения в производительности.

2. Сравнение результата со средними значениями

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

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

3. Сравнение результата со сценарием

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

Например, в сценарии указано, что метод GetUser должен отвечать не дольше 1 секунды.
В настройках сценария можно задать фиксированные/ожидаемые параметры.
Затем система позволит сравнить фактический результат с ожидаемыми значениями.

4. Сравнение средних значений со сценарием

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

Полезно при анализе общей картины нагрузки.
Например, если один из тестов неожиданно выбивается из ожидаемых значений (из-за временных сбоев), но в среднем результаты стабильны, это помогает избежать ложных тревог.
Также этот вид сравнения подходит для оценки новой функциональности — если для новой фичи проведено 10 запусков, можно проверить, насколько средний результат соответствует ожидаемым параметрам.

5. Сравнение метода со сценарием

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

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

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

Сравнение одного результата с несколькими другими

Разберем процесс сравнения одного результата с несколькими другими пошагово.

1. Выбор результатов для сравнения

Сначала выбираем результат, который хотим сравнить, и переходим в его детали.
В меню сравнений выбираем "Show comparison with results".
После этого открывается страница сравнения, где по умолчанию выбирается предыдущий результат, но можно добавить любые другие результаты для анализа.

2. Общий виджет сравнения метрик

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

Каждая метрика анализируется отдельно, рассчитывается общий процент отклонения с учетом весов метрик.
Первый виджет показывает средние и суммарные значения, ниже идет сравнение по методам.
Для методов также рассчитывается общий процент сравнения с применением весов.

3. Средние значения: виджет "Average summary"

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

Зачем это нужно?

Пример:
Вы тестируете новую фичу и провели 10 запусков нагрузочных тестов.
Выбираете один эталонный результат и сравниваете его с остальными, чтобы оценить стабильность производительности.

Если один из запусков аномальный (например, были проблемы с инфраструктурой: "моргнуло электричество" или появился "шумный сосед" на ноде), важно видеть, что в среднем результат укладывается в требования.

Виджет "Average summary" помогает выявить подобные ситуации и отделить реальные проблемы сервиса от инфраструктурных факторов.

4. Настройка отображаемых метрик

Для каждой таблицы сравнения есть гибкая настройка метрик.

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

5. Сравнение методов в модальном окне

Рядом с каждым методом в таблице есть кнопка с иконкой графика.

При нажатии открывается модальное окно, в котором отображается сравнение данного метода с выбранным результатом.

6. Графики сравнения методов

В модальном окне метода отображаются наложенные друг на друга графики для текущего и сравниваемого результата.

Важно:

Всегда отображаются только два результата – текущий и выбранный для сравнения.
Даже если выбрано 10 результатов, здесь будут только два.

Это позволяет сфокусироваться на сравнении динамики конкретного метода, например:

Выявить момент просадки RPS.
Понять, в какое время начались проблемы.
Оценить поведение метода в динамике.

7. Сравнение метода по всем результатам

Если необходимо сравнить метод сразу по всем выбранным результатам,

нужно нажать ту же кнопку графика, но уже на виджете "Average summary".
Откроется модальное окно с агрегацией данных, где все результаты будут наложены на один график.

8. Графики сравнения результатов

Ниже на странице отображаются отдельные графики для каждой метрики.

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

9. Настройка отображаемых графиков

На виджете "Compare charts" можно выбрать, какие графики отображать.

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

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

Рассмотрим функционал сравнения текущего результата со средними значениями.

Как это работает?

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

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

Как учитывается сценарий?

Логика расчета средних значений зависит от выбора сценария:

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

Это позволяет гибко анализировать среднюю производительность,
как в рамках одного сценария, так и по всему сервису в целом.

Сравнение результата со сценарием

В чем отличие от других сравнений?

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

Ожидаемые метрики можно задать прямо со страницы сравнения:

Нажав на шестеренку в правом верхнем углу панели управления
Или через виджет самого сценария

Как задать значения?

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

Как выглядит сравнение?

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

В чем польза?

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

Пример:

У нас есть требование: "Лента операций в мобильном приложении должна загружаться не более чем за 3 секунды"
Анализируем, какие методы вызываются на этой странице
Определяем ожидаемое время отклика для каждого метода
Задаем значения в сценарии, фиксируем производительность и отслеживаем отклонения

Сравнение средних значений со сценарием

Где отображается?

Виджет сравнения средних значений со сценарием доступен на странице "Dashboard", если выбран сценарий.

Что показывает?

Этот виджет оценивает соответствие средних значений всех результатов ожидаемым значениям сценария.

Логика работы:

Если сценарий выбран → Средние значения рассчитываются только для результатов этого сценария
Если сценарий не выбран → Средние значения считаются по всем результатам нагрузочного тестирования сервиса

Почему это удобно?

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

Сравнение метода со сценарием

Где отображается?

Этот виджет находится на странице деталей метода.

Что такое детали метода?
В load-testing-hub автоматически собирается аналитика по методам на основе результатов нагрузочного тестирования (НТ).
Все методы отображаются на странице "Methods", где можно просмотреть средние значения по каждому из них.
Подробнее об этом в разделе "Методы".

На странице деталей метода отображается виджет сравнения средних значений метода с ожидаемыми значениями из сценария.

Гибкость настроек

В настройках сценария можно задать:

Ожидаемые средние значения
Ожидаемые значения для каждого метода в отдельности

Итог

Функционал сравнения результатов значительно расширился по сравнению с MVP-версией load-testing-hub:

Больше опций настройки
Гибкость в выборе параметров
Объективная оценка производительности
Индивидуальные веса метрик
Больше типов сравнений результатов

Аналитика

Страница "Dashboard" предоставляет аналитическую информацию, позволяя оценить общие показатели нагрузочного тестирования (НТ) за определенный промежуток времени.
Одна из ключевых задач load-testing-hub — агрегация данных из НТ и их визуализация.

Основные виджеты

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

Графики динамики изменений средних значений

Каждая точка на графике представляет отдельный результат НТ, что позволяет отслеживать изменения во времени:

Total requests per second (Общее количество запросов в секунду)
Total requests per second
Total requests (Общее количество запросов)
Total requests
Response times (ms) (Время отклика)
Response times (ms)
Percentiles (ms) (Перцентили)
Percentiles (ms)

Графики распределения метрик по методам

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

Фильтрация данных

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

Сценарии и сравнительный анализ

Виджет сравнения средних значений со сценарием

Отображается только если выбран сценарий в настройках.
Позволяет анализировать данные исключительно в рамках конкретного сценария (например, при нагрузке новой фичи).

Сравнение ожидаемых и фактических значений метрик

В этом виджете сравниваются ожидаемые метрики сценария с фактическими средними значениями.
Отображается только если выбран сценарий.

Что изменилось по сравнению с MVP?

Больше данных: теперь отображаются перцентили, медиана времени отклика и больше метрик по методам.
Гибкие настройки графиков: можно выбирать, какие метрики отображать.
Удобство анализа: если на одном графике отображается Min response time = 10ms и Max response time = 3050ms,
то разница слишком большая, и min response time будет сложно увидеть.
Вместо создания множества графиков, добавлена возможность гибкой настройки отображаемых данных.

Методы

На странице "Methods" отображается список методов, автоматически агрегируемых из результатов нагрузочного тестирования (НТ). Основные задачи этой страницы — ответить на следующие вопросы:

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

Страница с деталями метода позволяет посмотреть графики с историей по метрикам метода, наблюдать динамику изменений, таких как рост или падение RPS (requests per second). Это помогает понять, какой именно метод может быть причиной ухудшения производительности или перегрузки системы.

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

Данные о методах можно фильтровать по дате и/или по названию метода. Это полезно, если нужно изучить средние показатели для конкретного метода за определенный промежуток времени.

При переходе в детали метода можно увидеть более подробную информацию по всем меткам и показателям.

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

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

Percentiles (ms)
Percentiles (ms) of method
Total requests per second
Total requests per second of method
Total requests
Total requests of method
Response times (ms)
Response times of method

Сценарии

На странице "Scenarios" отображается список сценариев для выбранного сервиса. Рассмотрим, что подразумевается под сценарием. Например, у нас есть мобильное приложение, и мы проводим нагрузочное тестирование методов, вызываемых на главном экране. Это будет один сценарий, назовем его main screen scenario. Если же мы тестируем методы, вызываемые на странице с лентой операций, это уже другой сценарий — operations screen scenario.

Таким образом, у нас есть два различных сценария: main screen scenario и operations screen scenario. Это важно, потому что анализировать статистику для каждого сценария стоит индивидуально, так как нагрузка, количество данных и другие факторы могут сильно отличаться. В load-testing-hub предусмотрены обе опции:

Анализ результатов для конкретного сценария
Анализ результатов в целом для сервиса или всех сценариев

Также стоит учесть, что у каждого сценария может быть своя версия. Например, мы запускаем сценарий operations screen scenario для 1000 виртуальных пользователей (версия сценария v1.0), а потом — для 5000 виртуальных пользователей (версия сценария v2.0). Таким образом, один и тот же сценарий может выполняться с разной нагрузкой на сервис. Для корректной аналитики важно анализировать результаты в рамках конкретной версии сценария.

Другой пример: у нас есть тот же сценарий operations screen scenario, и мы запускали его на 1500 виртуальных пользователей. Потом что-то изменилось, и теперь нужно запускать его на 3000 виртуальных пользователей. Важно понимать, что сравнивать результаты для 1500 и 3000 пользователей «на равных» неправильно. Поэтому можно создать новую версию сценария (например, v1.1) и анализировать статистику отдельно для 3000 виртуальных пользователей, что будет корректным подходом. Это также предусмотрено в load-testing-hub.

Настройки сценария

Важный момент: не стоит грузить один метод или эндпоинт "до посинения", поскольку в реальной эксплуатации пользователь не делает одно и то же действие на экране бесконечно. Нагрузочное тестирование должно моделировать реальные сценарии использования. Речь идет о нагрузочном тестировании, не путать с стресс-тестированием и тестированием отказоустойчивости, где действительно имеет смысл нагружать один эндпоинт до отказа системы.

В сценарии есть показатель ratio (распределение), который отражает процент нагрузки на каждый метод или эндпоинт. Этот показатель помогает понять, какой метод несет наибольшую нагрузку в сценарии.

Теги сценариев

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

LEGACY — для устаревших сценариев
LATEST — для последней актуальной версии сценария
EXPERIMENT — если сценарий был создан для проверки гипотезы или эксперимента

Теги имеют исключительно информационный характер, предоставляя метаинформацию о сценарии.

Удаление сценариев

Сценарий можно удалить, если он больше не актуален. Однако важно, что в load-testing-hub сценарий и все связанные с ним данные не удаляются окончательно — они просто скрываются из статистики, что позволяет сохранить историю данных для анализа в будущем.

Настройка ожидаемых значений для сценария

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

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

Настройка ожидаемых значений для методов сценария

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

Интеграции

На странице "Integrations" отображается список интеграций. Поясню, зачем это нужно. Каждая сущность интеграции содержит необходимые поля для построения ссылки на дашборд в Grafana или Kibana. Это позволяет не только просматривать результаты нагрузочного тестирования, но и анализировать, как вел себя сервис в момент нагрузки. В ссылку автоматически подставляются фильтры по времени и хост сервиса для Grafana/Kibana, что дает возможность отслеживать, как использовались память, диск и CPU в процессе нагрузки. Аналогично, можно анализировать логи в Kibana.

При создании интеграции пользователю показывается информационный алерт, который объясняет, как работают интеграции и как правильно прописывать шаблон ссылки, на основе которого будет формироваться финальная ссылка. Давайте кратко объясню, как это работает. В поле URL template можно ввести любую ссылку, при этом можно использовать плейсхолдеры для подстановки переменных. В настоящее время доступны следующие плейсхолдеры:

{host} — хост, который будет взят из настроек сервера и подставлен в ссылку в зависимости от типа интеграции.
{time_from} — время начала нагрузочного теста. Это позволяет ограничить фильтрацию данных в Grafana/Kibana по времени начала теста.
{time_to} — время окончания нагрузочного теста, аналогично работает для времени окончания теста.

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

Интеграции привязаны к конкретному сервису, что позволяет настраивать их индивидуально для каждого сервиса. Например, если у нас есть сервис gateway-service, который взаимодействует с account-service, а тот, в свою очередь, с user-service, то при нагрузочном тестировании сервиса gateway-service нам будет интересно наблюдать за сервисами gateway-service, account-service и user-service. Однако, при нагрузочном тестировании только account-service, нас не будет интересовать поведение gateway-service, а только account-service и user-service. В сервисе load-testing-hub можно настроить интеграции таким образом, чтобы видеть данные только по тем сервисам, которые нас интересуют.

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

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

Настройки

Общие настройки

Общие настройки сервиса load-testing-hub можно открыть, нажав на значок шестеренки в правом верхнем углу апп-бара. Эти настройки являются базовыми и применяются ко всей системе, например, выбор темной или светлой темы.

Настройки сервиса

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

Далее идут настройки весов метрик для сравнений. О весах метрик уже упоминалось ранее, но повторю, что для каждой метрики можно задать свой вес, или, по-другому, приоритет. Сумма всех весов метрик не может превышать 1 (или 100%). Это означает, что мы указываем, какой процент составляет каждая метрика при расчете общего процента сравнения. Мы также можем сфокусироваться только на одной метрике, выставив ей вес 1, а для остальных метрик установить вес 0.

Все метрики сгруппированы по их логическому значению. Например, все метрики, связанные с временем ответа, находятся в блоке Response times.

Далее идут настройки, которые отвечают за подсвечивание отклонений при сравнении результатов. Объясню на примере. Допустим, мы нагружаем сервис, и всегда присутствует погрешность в сравнении результатов, обычно она составляет +-20-30%, в зависимости от инфраструктуры и выделяемых ресурсов. Например, если сервис работает в облаке с Kubernetes, где каждый под конкурирует за ресурсы, погрешность может быть большой. Если же сервис работает на отдельной виртуальной машине с выделенным кластером, погрешность будет меньше. В случае, когда разница в производительности значительная, необходимо иметь индикатор, который подсветит отклонение и укажет, что нужно обратить внимание на результат НТ. Для этого существуют настройки "Compare highlight threshold", где можно задать процент, после которого отклонение будет подсвечиваться. Этот процент можно настроить для каждого типа сравнения индивидуально.

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

Также на основе данных об отклонении можно настроить уведомления в Slack. Для этого достаточно использовать API сервиса load-testing-hub и сделать @mention ответственного лица.

Загрузка результатов

Также хотелось бы обсудить, каким образом данные из артефактов инструмента нагрузочного тестирования попадают в систему load-testing-hub. Для этого предусмотрен специальный API, с помощью которого можно загрузить в систему любые данные.

Фактически использование сервиса не ограничено каким-либо языком или фреймворком. Любой современный фреймворк нагрузочного тестирования может экспортировать базовые метрики (RPS, среднее время отклика, динамику различных показателей в процессе нагрузки и т. д.) в удобный формат: CSV, JSON, Prometheus, Grafana, InfluxDB, Datadog и многие другие.

Подготовил пример для Python + Locust, который можно найти в репозитории load-tests-hub. По аналогии с ним можно написать скрипт для любого языка и фреймворка — достаточно получить данные из артефактов тестирования и привести их к формату, который принимает API load-testing-hub.

Если кратко, то необходимо отправить несколько запросов к API. Сейчас не буду останавливаться на этом подробно, так как детальная информация есть в репозитории load-tests-hub, но перечислю основные API-эндпоинты:

/api/v1/scenarios/{scenario_id} — обновляет данные сценария
/api/v1/load-test-results — создаёт результат нагрузочного теста
/api/v1/load-test-results-history — создаёт запись в истории нагрузочного теста
/api/v1/method-results — создаёт результат тестирования конкретного метода
/api/v1/method-results-history — создаёт запись в истории тестирования метода
/api/v1/ratio-results — создаёт результат распределения нагрузки в тесте
/api/v1/exception-results — создаёт результат обработки ошибок в нагрузочном тесте

На этом, в целом, всё. Как видите, здесь нет ничего сложного — обычное взаимодействие с REST API.

Важно отметить, что все запросы, кроме создания результата нагрузочного теста, являются опциональными. Это означает, что если какие-то данные не загрузить, они просто не отобразятся — при этом система не сломается, не выдаст ошибки и не крашнется. На мой взгляд, это делает load-testing-hub ещё более гибким и удобным инструментом.

Заключение

За время работы над load-testing-hub было проведено множество улучшений. Итоговые доработки включают:

Полностью переработанный функционал сравнений результатов, обеспечивающий более точный и удобный анализ.
Обновлённый набор собираемых и отображаемых метрик для более глубокого понимания результатов нагрузочного тестирования.
Улучшенные графики и аналитика:
- Возможность настройки отображаемых метрик.
- Поддержка zoom для детального изучения графиков.
Добавлена детализированная информация по каждому тестируемому методу, что помогает точнее анализировать их поведение под нагрузкой.
Внедрена подсветка проблемных результатов, отклоняющихся от допустимой погрешности, что упрощает выявление аномалий.
Реализована возможность удаления нагрузочных результатов, обеспечивая удобное управление историей тестов.
Добавлен удобный интерфейс для управления сервисами и сценариями:
- Создание, удаление и обновление напрямую из UI.
Существенные оптимизации на стороне сервера для повышения производительности и масштабируемости.
Добавлен отдельный блок для настройки интеграций, что упрощает подключение внешних инструментов.

Весь исходный код сервиса доступен на моем GitHub:

load-testing-hub-api — серверная часть, написанная на Python + FastAPI, предоставляющая API для клиента.
load-testing-hub-panel — UI часть, написанная на TypeScript + React.
load-tests-hub — пример загрузки результатов из нагрузочных тестов в сервис load-testing-hub для Locust + Python. Однако использование сервиса не ограничивается каким-либо фреймворком для нагрузочного тестирования или языком программирования — его можно использовать с любым инструментом и любым языком.

Буду рад ответить на любые вопросы по сервису load-testing-hub.

Правильный инструмент для аналитики нагрузочного тестирования. Часть 2