Возможные метрики производительности для веб-приложений

web-app_perfomance_available_metrics.markdown

Метрики производительности по скорости сайта (из статьи):

Время отклика сайта (получение статуса главной страницы) по запросу из адресной строки (Response Time) - это то же, что и время заголовка или другое?

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

Время старта рендера - время между запросом пользователя и моментом, когда контент появляется в браузере (Time to Start Render).

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

Время поиска DNS - время, затраченное DNS-провайдером на перевод доменного имени в IP-адрес. Такие службы, как Pingdom или Webpagetest, могут быстро вычислить время поиска DNS сайта для каждого домена.

Время соединения - время между вызовом сайта и установкой связи между браузером и сервером. Можно экспериментировать с инструментами тестирования загрузки, такими как LoadStorm или JMeter, чтобы моделировать тяжелые случаи. Чтобы гарантировать лучшее время соединения, нужно обновлять инфраструктуру, также можно разгрузить некоторые активы на сервер кэширования или CDN.

Время первого байта - время, которое требуется для получения браузером самого первого байта информации после установления связи с сервером - время первого байта, (TTFB - Time To First Byte). Порядок, в котором пользователь видит данные на экране, очень важен, и некоторые небольшие изменения в коде приложения могут улучшить эту метрику производительности сайта.

Время последнего байта - в момент получения браузером всех байтов сайта фиксируется время последнего байта (TTLB - Time To Last Byte). Качество кода и запросов к базе данных играет большую роль в этой метрике. Другие факторы, которые могут ухудшать TTLB, это неправильно сконфигурированный сервер или его перегрузка.

==================================================================================

"Какие вообще события должны быть измерены при тестировании производительности веб-приложения?" (из видео-доклада):

1. Время загрузки страницы на клиенте

2. Время генерации интерактивной страницы на сервере

3. Время загрузки файла (контента) - download/upload с сервера

4. Время отклика соединения

5. Время отображения данных на экране клиента

6. Время от соединения с сервером до готовности к пользовательскому вводу

7. Время между вводом адреса в адресную строку и последующим откликом HEAD

8. Время загрузки JVM отдельно (это серверная часть)

9. Загрузка приложением и его компонентами аппаратной части компьютера: CPU, swap, cache, I/O, RAM, Network

метрики_при_тестировании_производительности_приложений_наработки_июнь_2020.md

Метрики при тестировании производительности приложений (web / desktop)

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

• Время отклика. Измеряется с момента отправки запроса к серверу до получения последнего байта от сервера.

• Througpath "Срупаф" (пропускная способность). Его частая интерпретация ниже: Обработка сервером кол-ва запросов-респонсов в единицу времени. Клиентское приложение формирует HTTP-запрос и отправляет его на сервер. Серверное ПО данный запрос обрабатывает, формирует ответ и передает его обратно клиенту. Общее число запросов-ответов в секунду и есть интересующая нас метрика.

• Транзакции в секунду. Пользовательские транзакции – это последовательность действий пользователя в интерфейсе. Сравнивая реальное время прохождения транзакции с ожидаемой (или просто количество транзакций в секунду), мы сможем сделать вывод о том, насколько успешной системой было пройдено тестирование.

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

• Процент ошибок. Рассчитывается как отношение невалидных ответов к валидным за промежуток времени.

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

Дополнительные метрики:

• Потребление ресурсов центрального процессора (CPU, %)

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

• Потребление оперативной памяти (Memory usage, Mb)

Метрика, показывающая количество памяти, использованной приложением. Использованная память может делиться на три категории:

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

Private — объём адресного пространства, занятого процессом и не разделяемого с другими процессами.

Working Set — набор страниц памяти, недавно использованных процессом.

В случае, когда свободной памяти достаточно, страницы остаются в наборе, даже если они не используются. В случае, когда свободной памяти остается мало, использованные страницы удаляются. При работе приложения память заполняется ссылками на объекты, которые, в случае неиспользования, могут быть очищены специальным автоматическим процессом, называемым «сборщиком мусора» (англ. Garbage Collector). Время, затрачиваемое процессором на очистку памяти таким способом может быть значительным, в случае, когда процесс занял всю доступную память (в Java — так называемый «постоянный Full GC») или когда процессу выделены большие объёмы памяти, нуждающиеся в очистке. На время, требующееся для очистки памяти, доступ процесса к страницам выделенной памяти может быть заблокирован, что может повлиять на конечное время обработки этим процессом данных.

• Потребление сетевых ресурсов (канал поставщика услуг, нашего сетевого оборудования, конфигурации сети, файрволов)

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

• Работа с дисковой подсистемой (I/O Wait)

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

Советы для тестировщиков и аналитиков по тестированию производительности

Корреляция динамических параметров и построение скриптов должны быть основаны на реальном поведении пользователей. Иначе тестирование будет больше напоминать DDOS-атаку. Перед разработкой и запуском скриптов необходимо провести большую аналитическую работу, чтобы понять и подготовить детализированную методологию тестирования производительности. Важно принимать во внимание временные задержки между действиями пользователей и корректно размещает их в скриптах согласно поведению реальных пользователей. Функция кэширования должна воспроизводиться как для каждого виртуального пользователя, так и для реальных пользователей в промышленной эксплуатации системы. Виртуальные пользователи должны использовать заранее подготовленные тестовые данные и взаимодействовать с системой в поведенческой манере. Каждое действие должно иметь предварительно заданную вероятность и выполняться только определенным количеством пользователей. Чтобы найти функциональные дефекты, которые проявляются только при нагрузке, следует создавать скрипты с такими же наборами действий, как и у реальных пользователей. Это даст возможность проанализировать и воспроизвести запросы.