- Задержка
- Пропуск
- Время отклика
- Одновременные пользователи
- Виртуальные пользователи
- Транзакций в секунду
- Ramp up-период
- Ramp down-период
- Think Time
- Тесты Stress, Endurance, Volume
- Baseline
- Бенчмарки
Latency
Latency (Задержка): задержка при сетевом взаимодействии. Эта метрика времени, которое требуется для передачи данных по сети. В сети с большой метрикой Latency передача данных происходит с большой задержкой, и с большим временем ожидания (Response time).
Latency показывает время ожидания, которое тратит пользователь при отправке или получении данных из сети. Задержка сети измеряется временем пинга — передается небольшой пакет данных и получают подтверждение того, что он получен.
Throughput
Throughput (Пропускная способность или пропуск): обозначает средний объем данных, который может фактически пройти через сеть за определенное время.
Метрика Throughput показывает количество пакетов данных, которые успешно доходят до места назначения, и потерю пакетов данных.
Таким образом, пропускная способность определяет количество пользователей, которые могут получать доступ к сети в одно и то же время. Пропускную способность можно измерять как с помощью инструментов тестирования сети, так и вручную. Используются такие инструменты, как JMeter, Postman, LoadRunner, Locust, Gatling — они довольно просты в настройке и могут быть легко использованы для измерения пропускной способности.
Примечание
Сеть с низкой пропускной способностью и высокой задержкой с трудом справляется с передачей и обработкой большого объема данных, что приводит к перегрузкам и низкой производительности приложений. Напротив, сеть с высокой пропускной способностью и низкой задержкой работает быстро и эффективно. Пользователи ощущают улучшение производительности и повышение удовлетворенности.
Response time
Response time (Время отклика): общее время с момента, когда пользователь или клиент отправляет запрос системе или приложению, до момента получения ответа. На время отклика могут влиять различные факторы, такие как задержка, мощность сервера, запросы к базе данных, эффективность кода, кэширование и параллелизм (объясняется ниже).
Caching
Caching (Кэширование): это техника, которая улучшает скорость и производительность сайта путем хранения часто используемых данных или ресурсов в быстром и доступном месте, таком как браузер или кэширующий сервер и т.п.
Пример
Время отклика в 2 секунды может быть приемлемым для веб-страницы, но неприемлемым для приложения, работающего в режиме реального времени. Аналогично, время отклика в 10 миллисекунд может быть впечатляющим в случае запроса к базе данных, но не имеющим значения для сервиса потокового видео.
Concurrent Users
Concurrent Users (Одновременные пользователи): количество пользователей, использующих приложение одновременно. Чтобы имитировать сценарии тестирования производительности в реальном времени, мы должны проводить проверки максимального количества одновременных пользователей. Приложение до какого-то порога одновременных пользователей должно правильно работать.
Virtual Users
Virtual Users (Виртуальные пользователи): Если мы используем инструменты тестирования производительности типа JMeter, Locust, Postman и т.д., мы можем имитировать виртуальных пользователей. Такой «пользователь» не является реальным, а имитируется, для изучения реакции приложения на действия какого-то количества виртуальных пользователей. Виртуальные пользователи могут быть описаны в системе как потоки (threads); соответственно многопоточность используется для проверки параллельной работы виртуальных пользователей.
Transaction Per Seconds
Transaction Per Seconds (Количество транзакций в секунду): метрика для расчета производительности подсистем, которые обрабатывают стандартные транзакции и ориентированы на хранение данных.
TPS можно рассчитать по формуле:
T ÷ S = TPS
Где:
T = Количество транзакций
S = Количество секунд
TPS = Транзакции в секунду
Ramp up period
Ramp up period (Период нарастания): Метрика Ramp Up Time представляет собой задержку между началом теста и запуском всех виртуальных пользователей. Эта метрика не зависит от настройки Длительности (Duration) и определяет, сколько времени потребуется для «наращивания» от 0 до полного количества виртуальных пользователей.
Время Ramp Up Time должно быть достаточно большим, чтобы обеспечить плавность повышения нагрузки в начале теста; и достаточно малым, чтобы последние виртуальные пользователи начали «работать» до того, как закончат первые (стандартный случай). Сценарий должен имитировать реальные условия, но этим иногда становится сложно управлять, поэтому бывают очень разные Ramp Up Time.
Ramp down period
Ramp down period (Период спада): Ramp-up-тест проверяет «пиковую нагрузку», например когда приложение запускается, в то время как ramp down-тест изучает его поведение при уменьшении нагрузки, то есть при падении количества одновременных пользователей, после достижения (и поддержания) нагрузки.
Активное изменение нагрузки при помощи вариации периодов ее роста и падения может понадобиться в различных сценариях, например при тестировании устойчивости (выносливости) системы, о чём мы поговорим далее.
Для чего предназначены метрики Ramp Up и Down:
- Моделирование изменений нагрузки
- Мониторинг ресурсов
- Оценка восстановления системы
Think Time
Think Time (Время на размышление): в реальном мире пользователю требуется время, чтобы прочитать страницу, или заполнить данные в веб-форме. Такие действия создают временной промежуток между двумя действиями пользователя. Think Time имитирует этот промежуток, добавляя задержку между двумя действиями.
Protocol
Protocol (Протокол): метод связи между клиентом и сервером. Например, HTTP, TCP и т.д.
Stress tests
Stress tests (Стресс-тесты): измеряют устойчивость программного обеспечения и возможность обработки ошибок в условиях экстремально высокой нагрузки, и проверяют поведение приложения в критических ситуациях. Стресс-тесты определяют «точку отказа» тестируемого приложения, то есть нагрузку, при которой оно начинает выдавать ошибки или закрывается.
Зачем мы это делаем: находим точку отказа и проверяем, демонстрирует ли система эффективное управление ошибками в экстремальных условиях.
Endurance tests
Endurance tests (Тесты выносливости/стабильности/надежности/ устойчивости): нагрузка, которую мы получаем во время работы нашего приложения, повышается и оценивается в течение длительного времени. Если приложение будет получать «необычную» нагрузку длительное время, то оно должно быть способно эффективно с ней справляться.
Volume tests
Volume tests (Объемные тесты): Подача огромного количества данных, чаще всего это резкое увеличение базы данных. С помощью объемных тестов можно оценить влияние такой нагрузки на время отклика и изучить поведение системы.
Зачем проводят: Проверяют «емкость» системы, то есть ее производительность при увеличении объемов обрабатываемых данных в БД,
- Выявить проблемы, возникающие при работе с большим объемом данных
- Выявить момент, когда стабильность системы снижается
- Оценить и сравнить производительность при нормальном и большом объеме данных
Baseline
Baseline (Базовая линия или базовый уровень): При планировании тестов производительности нужно иметь некую базовую метрику для сравнения. Эта метрика показывает данные «базовой», текущей производительности, или минимальный уровень, которому приложение должно соответствовать.
Benchmarking
Benchmarking (Бенчмаркинг): После того как мы установили базовый уровень, можем начать бенчмаркинг (сопоставление и сравнительный анализ), выполняя нагрузочные тесты, или начать троттлинг (то есть симулировать медленное ухудшение скорости сети). Бенчмаркинг позволяет измерить, насколько улучшилось или ухудшилось состояние системы, сравнивая с базовым уровнем.
