В Amazon однажды посчитали: в случае увеличения времени загрузки сайта на 100 мс компания потеряла бы 1% продаж. Похожие расчёты Google продемонстрировали: если страницы будут загружаться на 500 мс дольше, это может привести к падению запросов на 25%. В Shopzilla сократили время на 5 секунд (с 7 до 2-х) и тем самым увеличили число просмотров на 25%, конверсию — на 12%. В Firefox при сокращении на 2,2 секунды увеличили конверсию загрузки на 15,4%.
Грамотно «прочитать» результаты нагрузочного тестирования и эффективно их использовать — не менее важно, чем провести сами тесты. Сделать это помогут правильные инструменты. Сегодня поговорим об основных метриках тестирования производительности, которые позволяют определить проблемные зоны приложения или сервиса, прежде чем вы с командой разработчиков начнёте вносить изменения для пользователей.
Основные метрики производительности
1. Время выполнения запроса или время отклика (Response Time)
Показывает, насколько быстро система отвечает на запрос пользователей (измеряется в миллисекундах). Пожалуй, важнейшая метрика. Пользователь предпочитают быстрые сервисы, и, если ваш работает медленно, уйдёт к конкурентам, ведь у него «на кончиках пальцев» — тысячи вариантов выбора.
Различают среднее время отклика — усредненный показатель разницы создания запросов и доставкой ответов по времени, и пиковое — самое долгое, затрачиваемое на отправку ответа. Если первый показатель даёт представление о производительности, то второй говорит о том, что приложение почему-то не отвечало, и может стать толчком к исследованию проблемы.
2. Пропускная способность (Throughput)
Данная метрика определяет способность приложения обрабатывать определённое число запросов за единицу времени (обычно измеряется в штуках в секунду). Это показатели количества данных, перемещаемых между серверами и устройствами пользователей, и помогает оценить общую производительность, выявить узкие места.
3. Количество виртуальных пользователей (Virtual Users)
В отличие от предыдущей метрики, показывает общее количество виртуальных пользователей (по-другому это поток — threads), а не за единицу времени.
В правильно спроектированном тесте их число приблизительно равно количеству реальных людей. Метрика особенно значима для стриминговых сайтов, например, транслирующих спортивные соревнования, когда на сайте присутствует большое число параллельных пользователей.
4. Количество ошибок (Error Rate)
Демонстрирует рост числа ошибочных запросов под нагрузкой, измеряется в штуках в секунду или в процентах от общего количества запросов. Высокий уровень ошибок — признак проблем в системе. Допустим, на каждые 100 запросов возникает 10 ошибочных, соответственно, показатель равен 10%.
Ошибки могут возникать по разным причинам: от неправильной конфигурации сервера до недостаточной масштабируемости приложения. Метрика позволяет выявить типы ошибочных запросов и уязвимости в коде приложения.
5. Точность воспроизведения профилей нагрузки
Эта метрика позволяет оценить, насколько тестовые сценарии соответствуют реальным сценариям поведения конечных пользователей. А ещё — сравнить подаваемую на систему нагрузку с расчётной.
Представим, что веб-сервис рассчитан на 100 параллельных пользователей, которые следуют определённому сценарию:
- 25 человек входят в систему, просматривают товар и выходят
- 25 при заходе не проявляют никакой активности
- 25 добавляют товар в корзину, оформляют его и покидают сервис
- 25 возвращают товар и выходят из системы.
Нагрузочное тестирование должно эмулировать этот типичный сценарий работы, и чем меньше система отклоняется от ожидаемой нагрузки, тем лучше результаты тестирования.
6. Использование аппаратных ресурсов системы (Utilization hardware)
Данные метрики не являются непосредственно метриками производительности (бизнес-метриками), однако помогают прослеживать корреляционные связи, указывающие на узкие места и пределы работы под нагрузкой.
Использование CPU
С помощью этой метрики увидим, какое время центральный процессор затратил на вычисления. Анализируя показатель потребления, можно выявить влияние объёмов данных, которые подвергаются обработке, конфигурации приложения и ОС и других факторов на производительность системы.
Оперативная память
Здесь определяем, какой объём использован приложением, и чем больше использовано, тем больше времени понадобится на очистку, что в конечном итоге может оказывать влияние на время обработки запросов.
Сетевые ресурсы
Представим, что сервер приложения, согласно требованиям, должен одномоментно обрабатывать 10 запросов пользователей. Но тестирование показывает способность отвечать только 9-ым — сетевое соединение обладает недостаточной пропускной способностью. Соответственно, делаем вывод, что система не соответствует расчётным требованиям производительности.
Работа с диском
Когда мы имеем большое количество записей и чтений, процессор может простаивать, ожидая обработки объёмов данных с диска, а это в свою очередь приведёт к повышенному потреблению его ресурсов и увеличению времени отклика.
Частые ошибки при анализе
Итак, тестирование проведено, графики получены. Теперь нужно проанализировать данные, понять, всё ли устраивает. Ошибки, которые могут искажать общую картину производительности, случаются и на этапе анализа результатов. Посмотри на некоторые из них.
Нереалистичное моделирование реальной нагрузки
Часто разработчики нагрузочных тестов не уделяют достаточного внимания созданию модели, которая отражала бы реальное разнообразие запросов и действий пользователей. Результаты таких тестов могут быть неполными или искаженными. В итоге, когда придут реальные люди, система может перестать отвечать.
С другой стороны, тестовая нагрузка должна быть разумной. Можно перегрузить систему избыточным числом запросов, блокирующих обработку. Допустим, вы подали на систему 100 пользователей, а она изначально была спроектирована только на 50. Вспомните, что происходит при DDoS-атаках, когда объём массовых запросов к серверу превышает допустимый?.. Необходимо изначально стремиться к тому, чтобы ваш расчетный сценарий был близок к «боевому».
Неправильная интерпретация данных тестирования
Представим, что вы столкнулись с увеличением времени обработки запроса. Причины могут быть разные. Например, избыточная нагрузка, проблема с сетью, ошибка в коде. Следствием неверной интерпретации может быть неправильное решение проблемы.
Игнорирование влияния внешних факторов на производительность
Нагрузка на сеть, интеграционные связи со смежными подсистемами, производительность аппаратного обеспечения, настройки серверов или даже временные изменения в работе системы — всё это может серьёзно влиять на результаты тестирования. Если не иметь ввиду эти факторы, есть риск сделать неверные выводы о состоянии системы.
Неправильный выбор инструментов
Необходим инструмент, который позволит не только провести само тестирование, но и составить понятный и полезный отчёт о результатах. Какой смысл тестировать, если мы не сможем понять, какие именно результаты мы получили или неверно интерпретируем их?
Анализ результатов: пример с использованием инструмента JMeter
Gatling, MF LoadRunner и Apache JMeter — на сегодня ведущие инструменты для нагрузочного тестирования. Они наиболее востребованы благодаря тому, что позволяют не только сгенерировать готовый отчёт, но и построить отдельные графики и проанализировать какие-то конкретные «сырые» данные. Чем это удобно? У каждого тестирования есть свои цели. И отчёт должен давать ответы в соответствии с этими целями. Нет никакого смысла включать в него все графики, если они не показательны и не релевантны целям.
А ещё важно добавить, что эти инструменты позволяют видеть не только сами показатели, но и корреляционные связи между метриками. Зачастую именно наложение и взаимосвязь помогают выявить, где именно случаются ограничения производительности.
Итак, как анализировать данные, рассмотрим на примере JMeter с упоминанием двух других популярных инструментов.
Таблица с временами отклика
Данная таблица (Aggregate Report) включает различные показатели, в том числе перцентили, среднее и максимальное время обработки запроса, пропускную способность и информацию об ошибках. Позволяет мониторить соответствие данных нефункциональным требованиям. Обычно в SLA указаны значения перцентилей 95 и 99, а также определённый процент ошибок. Сравнивая, мы можем быстро оценить результаты тестирования и выявить превышение.
В Gatling эти данные по аналогии можно получить из таблицы, в MF LoadRunner — из Transaction Summary.
График Virtual Users
Здесь мы можем видеть число потоков (в Apache JMeter) или виртуальных пользователей (MF LoadRunner,Gatling), которые взаимодействуют с системой в течение определенного периода времени и благодаря этому позволяют контролировать нагрузку. Если график показывает большое отклонение вверх, это может означать, что есть ошибка в расчётах, или вы перегрузили систему виртуальными пользователями или о других проблемах.
Обычно представлен в двух видах:
- «Active Users». Показатель количества потоков, которые в настоящее время активны в системе. Может колебаться в течение всего теста, особенно в случае открытой модели нагрузки, когда потоки постоянно стартуют и останавливаются.
- «Total Users». Отображает общее количество потоков, которые были запущены и завершили свою работу с начала тестов. Этот параметр полезен при закрытой модели нагрузки. Ведь в данном случае количество потоков остается постоянным и не меняется в течение теста.
График Response Time
Отображает время отклика на запросы. В Apache JMeter — Response Times Over Time. В MF LoadRunner и Gatling смотрим график Average Transaction Response Time. Время не должно выходить за нефункциональное требование (SLA). В идеале — равномерное течение всего теста, без пиковых показателей и при этом соответствует росту нагрузки.
Корреляцию между её увеличением и ростом времени отклика удобно отслеживать при наложении данного графика с VU/RPS (о этом ниже). В JMeter для этой цели существует Response Times vs Threads.
График Request Per Second
Даёт представление, какое число запросов поступает в систему за одну секунду (единица измерения — шт./сек.). В MF LoadRunner и Apache JMeter — это Hits per Second.
Ещё один важнейший инструмент, благодаря которому мы можем оценить, какую нагрузку способна «взять» система. А ещё выявить выход за пределы SLA: запросы скапливаются или заканчиваются по времени в случае деградации системы. На графике это отображается в виде провалов и скачков.
Рассматривая график в контексте VU, мы можем отследить корреляцию числа запросов и пользователей, а также видеть, как снижается нагрузка с окончанием сеансов. А когда анализируем вместе с Response Time, можно оценить среднее время обработки транзакций в течение всего теста.
График Errors
Отображает число ошибочных запросов и позволяет следить за их уровнем в рамках установленных пределов. Анализируя эти данные в контексте Response Time, можем проанализировать, как количество ошибок взаимосвязано со временем отклика системы. В Apache JMeter график ошибочных запросов объединен с VU и даёт возможность наблюдать за влиянием на этот показатель роста нагрузки.
Как видим, все перечисленные графики и таблицы обеспечивают отличную читаемость результатов тестирования. Анализируя их в совокупности, легче выявить проблемы производительности в системе и выбрать пути решения.
Альтернативным и удобным инструментом для визуализации и анализа метрик может выступить инструмент Grafana. Позволяет построить информативные дашборды, интегрируя данные из разных источников: баз данных, сервисов мониторинга или инструментов тестирования. Grafana визуально информативна, позволяет легче обнаруживать аномалии и анализировать производительность системы, что в конечном итоге вы сможете обратить в практические улучшения для ваших пользователей.