Метрики тестирования производительности

Введение в метрики производительности: основные понятия и цели измерений

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

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

Что такое тестирование производительности?

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

Мы не ищем функциональные баги (например, «кнопка не работает»), мы ищем «узкие места» (bottlenecks), которые замедляют работу приложения или приводят к его падению при наплыве пользователей.

!Схематичное изображение потока запросов от пользователей к системе, демонстрирующее точки, где возникают задержки и нагрузка.

Зачем нам нужны метрики?

Метрика — это количественная мера степени, в которой система, компонент или процесс обладают данным атрибутом. В контексте производительности метрики отвечают на вопросы «Как быстро?» и «Сколько?».

Основные цели сбора метрик:

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

Планирование мощностей (Capacity Planning). Метрики подсказывают, сколько серверов нужно купить, чтобы выдержать «Черную пятницу».

Поиск узких мест. Что тормозит систему: медленный код, база данных или сеть?

Проверка SLA (Service Level Agreement). Соответствует ли система заявленным требованиям (например, «99% запросов должны обрабатываться быстрее 1 секунды»).

Три кита производительности

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

1. Время отклика (Response Time / Latency)

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

Важно понимать, что время отклика складывается из нескольких этапов: * Время отправки запроса по сети. * Время обработки запроса на сервере (Server Processing Time). * Время работы базы данных. * Время получения ответа по сети.

> «Быстродействие — это не фича, это требование».

2. Пропускная способность (Throughput)

Эта метрика показывает, какой объем работы система может выполнить за единицу времени. Обычно она измеряется в: * RPS (Requests Per Second) — количество запросов в секунду. * TPS (Transactions Per Second) — количество бизнес-транзакций в секунду (транзакция может состоять из нескольких запросов).

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

3. Утилизация ресурсов (Resource Utilization)

Это метрики «здоровья» серверов. Они показывают, сколько ресурсов потребляет система под нагрузкой. Основные показатели: * CPU Usage: Загрузка процессора. * Memory Usage: Потребление оперативной памяти. * Disk I/O: Операции ввода-вывода на жестком диске. * Network I/O: Загрузка сетевого канала.

Если утилизация одного из ресурсов приближается к 100%, это становится «бутылочным горлышком», ограничивающим пропускную способность и увеличивающим время отклика.

Математическая связь метрик: Закон Литтла

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

Формула выглядит следующим образом:

Где: * — среднее количество запросов, находящихся в системе одновременно (или количество одновременных пользователей, Concurrency). * — пропускная способность системы (Throughput), то есть скорость поступления и обработки заявок. * — среднее время пребывания запроса в системе (Response Time).

Пример использования: Допустим, вы знаете, что ваша система должна выдерживать 100 одновременных пользователей (), и вы хотите, чтобы среднее время отклика было не более 0,5 секунды (). Какую пропускную способность должен обеспечивать ваш сервер?

Используя формулу, мы можем выразить :

Где: * — искомая пропускная способность. * — количество пользователей (числитель). * — время отклика (знаменатель).

Подставим значения:

Где: * — это требуемое количество запросов в секунду (RPS).

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

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

Уровень ошибок (Error Rate)

Нельзя говорить о производительности, игнорируя ошибки. Если система отвечает мгновенно, но возвращает ошибку «500 Internal Server Error», это не высокая производительность, а отказ обслуживания.

Error Rate — это процент запросов, завершившихся ошибкой, по отношению к общему числу запросов. Обычно вычисляется по формуле:

Где: * — уровень ошибок в процентах. * — количество ошибочных запросов. * — общее количество отправленных запросов.

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

Клиентские и серверные метрики

Важно различать, где мы измеряем показатели.

Серверные метрики (Backend Metrics): Измеряются на стороне сервера. Показывают, как быстро сервер обработал запрос. Не учитывают время доставки по сети и рендеринг в браузере.

Клиентские метрики (Frontend Metrics): Измеряются на устройстве пользователя. Включают в себя время сети, парсинг HTML/JS, отрисовку страницы. Для пользователя важны именно они.

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

Резюме

Сегодня мы заложили первый камень в фундамент ваших знаний о нагрузочном тестировании. Мы выяснили, что: * Тестирование производительности ищет узкие места, а не функциональные баги. * Основные метрики — это Время отклика, Пропускная способность и Утилизация ресурсов. * Закон Литтла связывает нагрузку, скорость и время отклика математически. * Ошибки — это тоже часть метрик производительности.

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

Временные метрики: время отклика, латентность и важность перцентилей

В предыдущей статье мы познакомились с «тремя китами» производительности: временем отклика, пропускной способностью и утилизацией ресурсов. Мы выяснили, что время отклика — это ключевой показатель для конечного пользователя. Если сайт грузится долго, пользователь уходит. Всё просто.

Однако, когда мы начинаем погружаться в детали, возникает путаница. Что такое «латентность»? Чем она отличается от «времени отклика»? И почему, если ваш отчет показывает «среднее время загрузки 2 секунды», пользователи жалуются на тормоза?

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

Анатомия времени: Response Time vs Latency

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

Latency (Латентность / Задержка)

Латентность — это время, которое требуется сигналу (пакету данных) для прохождения от отправителя к получателю. Это «время в пути». Оно зависит от физического расстояния, качества сети, количества маршрутизаторов и скорости света.

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

Response Time (Время отклика)

Время отклика — это полное время, которое проходит с момента отправки запроса клиентом до момента получения ответа. Оно включает в себя латентность (дорогу туда и обратно) и время обработки запроса сервером.

Математически это можно выразить так:

Где: * — полное время отклика. * — сетевая задержка в одну сторону (поэтому умножаем на 2: запрос к серверу + ответ от сервера). * — время, которое сервер потратил на «обдумывание» запроса (работа кода, базы данных).

!Визуализация составляющих времени отклика: сеть и обработка.

Почему это важно различать?

Если ваше время отклика высокое ( секунд), вам нужно понять, где проблема:

Если высокое (например, секунды), а низкое ( секунды) — проблема в сети. Оптимизировать код бесполезно, нужно менять хостинг, использовать CDN или уменьшать размер передаваемых данных.

Если низкое ( секунды), а высокое ( секунды) — проблема в коде или базе данных. Нужно профилировать приложение.

> «Не пытайтесь оптимизировать SQL-запрос, если ваш сервер находится в Австралии, а пользователи — в Лондоне. Сначала решите проблему физики».

Ловушка среднего значения (The Average Trap)

Самая распространенная ошибка новичков — ориентироваться на среднее арифметическое (Mean/Average) при анализе результатов теста.

Формула среднего арифметического знакома всем со школы:

Где: * — среднее значение. * — сумма всех измеренных времен отклика. * — общее количество запросов.

Почему среднее врет?

Представьте, что мы измеряем благосостояние людей в баре. В баре сидят 9 работяг с зарплатой 50 000 рублей. Внезапно в бар заходит миллиардер. Средняя зарплата в баре мгновенно становится несколько миллионов рублей. Значит ли это, что работяги стали богаче? Нет.

То же самое происходит в нагрузочном тестировании. Допустим, вы сделали 100 запросов: * 99 запросов выполнились за 0.1 секунды. * 1 запрос «завис» и выполнялся 100 секунд (тайм-аут).

Посчитаем среднее:

Где: * — полученное среднее время отклика.

Ваш отчет скажет: «Среднее время отклика — 1.1 секунды». Это выглядит приемлемо. Но на самом деле один пользователь испытал чудовищную боль (100 секунд ожидания), а статистика это скрыла, «размазав» проблему по всем остальным.

В реальных системах распределение времени отклика почти никогда не бывает нормальным (как колокол). Оно имеет «длинный хвост» (Long Tail) — небольшое количество очень медленных запросов, которые портят жизнь пользователям.

!Распределение с «длинным хвостом»: большинство запросов быстрые, но выбросы искажают картину.

Перцентили: Истина в деталях

Чтобы увидеть реальную картину, мы используем перцентили (Percentiles). Перцентиль показывает, какое значение не превышает определенный процент измерений.

Если мы говорим, что 90-й перцентиль (p90) равен 2 секундам, это означает, что 90% всех запросов выполнились быстрее или за 2 секунды. И только 10% были медленнее.

Ключевые перцентили

p50 (Медиана): Это середина. 50% запросов быстрее этого значения, 50% медленнее. Медиана намного устойчивее к выбросам, чем среднее арифметическое. В примере с миллиардером в баре медианная зарплата осталась бы 50 000 рублей.

p90: Стандартный показатель для большинства веб-систем. Показывает опыт большинства пользователей.

p95, p99: Это показатели «хвоста». Они показывают, как система работает для самых «невезучих» пользователей. В высоконагруженных системах (HighLoad) борьба идет именно за p99.

Пример чтения отчета

Давайте посмотрим на таблицу результатов теста:

| Метрика | Значение | | :--- | :--- | | Min | 0.1 с | | Average | 2.5 с | | p50 (Median) | 0.2 с | | p90 | 0.5 с | | p99 | 30.0 с | | Max | 35.0 с |

Анализ: * Min (0.1 с) и p50 (0.2 с): Система в целом работает очень быстро. Половина пользователей получает ответ мгновенно. * p90 (0.5 с): Даже 90% пользователей довольны. * Average (2.5 с): Среднее значение сильно завышено. * p99 (30.0 с): Вот она, проблема! 1% пользователей (каждый сотый) ждет полминуты. Именно этот 1% запросов «утянул» среднее значение вверх.

Если бы мы смотрели только на Average, мы бы думали, что система просто «немного медленная». Глядя на p99, мы понимаем, что система работает отлично для большинства, но иногда случаются катастрофические «залипания» (например, блокировки в базе данных или сборка мусора).

Стандартное отклонение (Standard Deviation)

Еще одна полезная метрика — стандартное отклонение (обозначается как или StdDev). Она показывает, насколько сильно значения разбросаны вокруг среднего.

Формула для генеральной совокупности:

Где: * — стандартное отклонение. * — конкретное значение измерения. * — среднее значение. * — количество измерений.

Вам не нужно считать это вручную, инструменты тестирования делают это сами. Важно понимать смысл: * Низкое StdDev: График узкий и высокий. Результаты стабильны. Если p50 = 0.5с, то почти все запросы будут около 0.5с. * Высокое StdDev: График широкий и плоский. Результаты нестабильны (Jitter). Один запрос 0.1с, другой 5с. Нестабильность раздражает пользователей больше, чем стабильная медлительность.

Как выбирать метрики для SLA?

Когда вы договариваетесь с бизнесом о требованиях (SLA — Service Level Agreement), никогда не используйте среднее время.

Плохой SLA: > «Среднее время отклика должно быть не более 1 секунды».

Хороший SLA: > «95% запросов (p95) должны обрабатываться быстрее 1 секунды, а 99% запросов (p99) — быстрее 3 секунд».

Такой подход защищает бизнес от ситуации, когда 90% пользователей летают, а 10% не могут оформить заказ.

Резюме

Время отклика Латентность. Время отклика включает в себя обработку на сервере, а латентность — только сеть.

Среднее значение — зло. Оно скрывает проблемы и чувствительно к выбросам.

Используйте перцентили. p50, p90, p95 и p99 дают объемную картину производительности.

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

Теперь, когда мы разобрались со временем, нам нужно понять, как измерять объем работы, который выполняет система. В следующей статье мы детально разберем метрики Пропускной способности (RPS, TPS) и узнаем, чем они отличаются друг от друга.

Показатели пропускной способности: RPS, TPS и объем передаваемых данных

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

Сегодня мы переходим ко второму киту производительности — Пропускной способности (Throughput). Мы разберем, чем отличаются RPS и TPS, почему их часто путают, и когда размер передаваемых данных становится важнее количества запросов.

Что такое пропускная способность?

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

Если время отклика отвечает на вопрос «Как быстро?», то пропускная способность отвечает на вопрос «Сколько?».

Представьте водопроводную трубу. * Скорость, с которой капля воды пролетает от начала до конца трубы — это Время отклика (Latency). * Количество литров воды, вытекающих из трубы за секунду — это Пропускная способность (Throughput).

В IT-системах «литрами» могут быть запросы, транзакции или байты данных.

RPS: Запросы в секунду

Самая базовая и распространенная метрика — RPS (Requests Per Second). Она показывает количество HTTP-запросов (или других сетевых вызовов), которые сервер успешно обрабатывает каждую секунду.

Формула расчета проста:

Где: * — искомое количество запросов в секунду. * — общее количество обработанных запросов за время теста. * — длительность теста в секундах.

Пример: Вы запустили тест на 10 минут (600 секунд). За это время сервер ответил на 120 000 запросов.

Где: * — это средний показатель RPS. Сервер обрабатывал 200 запросов каждую секунду.

Когда использовать RPS?

Эта метрика идеальна для технического мониторинга. Она показывает нагрузку на веб-сервер (Nginx, Apache), сервер приложений или базу данных. Системные администраторы и DevOps-инженеры мыслят именно в категориях RPS.

TPS: Транзакции в секунду

Здесь начинается путаница. Часто термины RPS и TPS используют как синонимы, но в контексте нагрузочного тестирования это разные вещи.

TPS (Transactions Per Second) — это количество бизнес-операций (транзакций), выполняемых в секунду.

Бизнес-транзакция — это логическое действие пользователя, которое имеет для него смысл. Например: «Оформить заказ», «Залогиниться», «Найти товар».

Одна бизнес-транзакция часто состоит из нескольких технических запросов (RPS).

Рассмотрим пример транзакции «Покупка товара»:

POST /api/login (Авторизация) — 1 запрос.

GET /api/products (Поиск товара) — 1 запрос.

POST /api/cart (Добавление в корзину) — 1 запрос.

POST /api/checkout (Оплата) — 1 запрос.

Итого: 1 Транзакция = 4 Запроса.

!Визуализация различия между одной транзакцией и составляющими её запросами.

Математическая связь RPS и TPS

Связь между этими метриками описывается формулой:

Где: * — количество технических запросов в секунду. * — количество бизнес-транзакций в секунду. * — коэффициент сложности транзакции (среднее количество запросов в одной транзакции).

Если ваш начальник говорит: «Мы ожидаем 1000 пользователей, каждый делает покупку раз в секунду» (то есть 1000 TPS), а в покупке 4 запроса (), то вы должны готовить сервер к нагрузке:

Где: * — целевой показатель RPS, который должна выдержать система.

Почему это важно?

Бизнес мыслит в TPS («Сколько продаж мы делаем?»). Инженеры мыслят в RPS («Выдержит ли база данных?»). Ваша задача как тестировщика производительности — переводить с языка бизнеса на язык инженеров, используя коэффициент .

Сетевая пропускная способность (Network Throughput)

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

Эта метрика измеряет объем данных, передаваемых через сеть за единицу времени. Обычно измеряется в: * Мбит/с (Mbps) — мегабиты в секунду (скорость канала). * МБ/с (MB/s) — мегабайты в секунду (объем данных).

Важно помнить соотношение:

Где: * — один байт информации. * — восемь бит.

Если у вас канал 100 Мбит/с, то максимальная теоретическая скорость скачивания:

Где: * — максимальная скорость передачи данных в мегабайтах.

Когда важен объем данных?

Видеостриминг и файлы. Если вы тестируете YouTube или файлообменник, эта метрика важнее, чем RPS.

Большие JSON/XML ответы. Иногда один запрос возвращает список из 10 000 товаров весом в 5 МБ. Даже при низком RPS (10 запросов в секунду) вы забьете канал 50 МБ/с (400 Мбит/с).

Точка насыщения (Saturation Point)

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

Представьте график, где по оси X — количество пользователей, а по оси Y — RPS.

Линейный рост. Сначала, добавляя пользователей, мы видим пропорциональный рост RPS. Система справляется.

Плато (Saturation). В какой-то момент добавление новых пользователей перестает увеличивать RPS. График выравнивается. Это значит, что один из ресурсов (CPU, диск, сеть) загружен на 100%.

Деградация (Buckling Zone). Если продолжить увеличивать нагрузку, RPS может резко упасть, а время отклика устремиться в бесконечность. Система «захлебывается» очередями.

!График производительности, демонстрирующий точку насыщения системы.

Ваша цель в тестировании — найти эту точку насыщения. Это и есть реальная максимальная производительность вашей системы.

Резюме

RPS (Requests Per Second) — техническая метрика, показывающая нагрузку на сервер в запросах.

TPS (Transactions Per Second) — бизнес-метрика, показывающая количество выполненных пользовательских сценариев.

RPS всегда больше или равен TPS. Коэффициент зависит от сложности сценария.

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

Ищите точку насыщения. Максимальный RPS — это предел, после которого система перестает быть стабильной.

Теперь, когда мы знаем, как измерять время (Latency) и скорость (Throughput), нам нужно разобраться с ресурсами, которые тратятся на эту работу. В следующей статье мы поговорим об Утилизации ресурсов: CPU, Memory, Disk и Network.

Утилизация системных ресурсов: мониторинг CPU, памяти, диска и сети

Мы продолжаем наш курс «Метрики тестирования производительности». В прошлых статьях мы научились измерять внешние проявления работы системы: как быстро она отвечает пользователю (Время отклика) и какой объем работы выполняет (Пропускная способность).

Но смотреть только на эти метрики — все равно что оценивать состояние бегуна только по его скорости. Бегун может бежать быстро, но если его пульс 200 ударов в минуту, а кислород в крови падает, он скоро упадет.

Сегодня мы заглянем «под капот» и разберем метрики здоровья серверов, или утилизацию ресурсов (Resource Utilization). Мы узнаем, почему 100% загрузки процессора — это не всегда плохо, когда оперативная память начинает убивать производительность и что такое IOPS.

Зачем мониторить ресурсы?

Мониторинг ресурсов отвечает на вопрос: «Какой ценой система обеспечивает текущую производительность?».

Основные цели мониторинга ресурсов:

Поиск узких мест (Bottlenecks). Что именно мешает системе работать быстрее: слабый процессор, медленный диск или нехватка памяти?

Планирование мощностей (Capacity Planning). Если при 1000 пользователях процессор загружен на 50%, мы можем прогнозировать, что сервер выдержит 2000 пользователей.

Предотвращение аварий. Высокая утилизация часто является предвестником отказа системы.

Мы будем рассматривать четыре главных ресурса, которые инженеры называют аббревиатурой USE (по методологии Брендана Грегга, о которой поговорим в конце): CPU, Memory, Disk, Network.

1. CPU: Центральный процессор

Процессор — это мозг сервера. Его загрузка (CPU Utilization) — самая популярная метрика, но и самая неправильно интерпретируемая.

Структура потребления CPU

Когда вы видите график «CPU 80%», важно понимать, на что именно тратятся эти проценты. Время процессора делится на несколько категорий:

* User Time (us): Время, затраченное на выполнение кода вашего приложения (бизнес-логика, расчеты, обработка JSON). Это «полезная» работа. * System Time (sy): Время, затраченное ядром операционной системы на обслуживание вашего приложения (работа с сетью, чтение файлов, выделение памяти). Если этот показатель высок, возможно, проблема в драйверах или слишком частых системных вызовах. * Idle Time (id): Время бездействия. Процессор ничего не делает. I/O Wait (wa): Процессор готов работать, но ждет, пока данные придут с диска или из сети. Это критически важный показатель! Высокий iowait* означает, что узкое место не в процессоре, а в дисковой подсистеме.

!Пример распределения времени работы процессора, где видно, что значительная часть времени тратится на ожидание ввода-вывода (I/O Wait).

Load Average: Очередь задач

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

Для этого существует метрика Load Average (средняя загрузка). Она показывает среднее количество процессов, которые либо исполняются, либо ждут своей очереди на исполнение.

Представьте мост (процессор): * Если на мосту едут машины, но есть свободное место — загрузка меньше 100%. * Если мост полон машин — загрузка 100%. * Если мост полон, и перед въездом стоит пробка из машин, ожидающих въезда — загрузка 100%, но Load Average растет.

Если у вас 4-ядерный процессор, то: * Load Average = 2.0 (Система недогружена, занято 2 ядра из 4). * Load Average = 4.0 (Идеальная полная утилизация). * Load Average = 8.0 (Перегрузка: на каждое ядро приходится по 2 процесса, один работает, один ждет).

2. Memory: Оперативная память

Оперативная память (RAM) — это рабочий стол системы. Если стола не хватает, приходится класть документы на пол (медленный жесткий диск).

Used vs Cached

Новички часто пугаются, увидев в Linux, что свободной памяти (Free) почти нет.

> «Linux ate my RAM!»

На самом деле, операционные системы используют свободную память для кэширования файлов с диска (Cache/Buffer), чтобы ускорить работу. Эта память формально занята, но при необходимости мгновенно освобождается для приложений.

Поэтому формула реальной утилизации памяти выглядит так:

Где: * — реально используемая приложениями память. * — общий объем памяти на сервере. * — абсолютно свободная память. * — память, занятая под кэш файловой системы (которую можно считать свободной).

Swapping (Подкачка)

Самая страшная метрика для памяти — это Swap Usage.

Когда оперативная память заканчивается, ОС начинает сбрасывать редко используемые данные на жесткий диск в специальный раздел (Swap). Диск работает в тысячи раз медленнее оперативной памяти.

Если вы видите активность Swap (Swap In / Swap Out) во время теста — это гарантия деградации производительности. Время отклика резко вырастет.

3. Disk I/O: Дисковая подсистема

Диск — это склад данных. Даже если у вас быстрый SSD, он все равно является самым медленным компонентом сервера.

Основные метрики диска

IOPS (Input/Output Operations Per Second): Количество операций чтения/записи в секунду. Эта метрика важна для баз данных, которые делают много мелких чтений.

Throughput (Пропускная способность): Объем данных в МБ/с. Важна для стриминга видео или копирования файлов.

Latency (Задержка диска): Время выполнения одной операции.

Queue Length (Длина очереди): Количество запросов к диску, ожидающих выполнения.

Random vs Sequential

Важно понимать характер нагрузки. * Последовательный доступ (Sequential): Чтение большого файла целиком. Диски делают это быстро. * Случайный доступ (Random): Чтение разбросанных кусков данных (типично для баз данных). Это самая тяжелая нагрузка для диска.

!Визуализация разницы между последовательным и случайным доступом к данным, объясняющая падение производительности при Random I/O.

4. Network: Сеть

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

Saturation (Насыщение)

Главная проблема сети — насыщение канала. Если у вас сетевая карта 1 Гбит/с, а трафик достигает 950 Мбит/с, начинаются коллизии и очереди.

Формула утилизации сети:

Где: * — утилизация сети в процентах. * — текущая скорость передачи данных (бит/с). * — максимальная пропускная способность интерфейса (бит/с).

Packet Loss и Retransmits

Если канал забит или оборудование не справляется, пакеты начинают теряться (Packet Loss). Протокол TCP пытается отправить их заново (Retransmits).

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

Методология USE

Чтобы не запутаться во всех этих метриках, Брендан Грегг (известный инженер по производительности) предложил методологию USE. Для каждого ресурса (CPU, Memory, Disk, Network) нужно проверить три параметра:

Utilization (Утилизация): Сколько времени ресурс был занят полезной работой? (например, CPU 70%).

Saturation (Насыщение): Есть ли очередь задач, которые не могут быть обработаны прямо сейчас? (например, Load Average или Disk Queue).

Errors (Ошибки): Возникают ли ошибки при работе с ресурсом? (например, Disk I/O Errors, Network Packet Drops).

Если Utilization близка к 100%, Saturation растет, а Errors появляются — вы нашли узкое место.

Резюме

CPU: Высокая загрузка не всегда плоха, если это User Time. Бойтесь высокого I/O Wait (проблема диска) и высокого Load Average (очереди).

Memory: Свободная память (Free) может быть низкой из-за кэша. Главный враг — это Swap.

Disk: Различайте IOPS (количество операций) и Throughput (объем). Случайное чтение убивает производительность диска.

Network: Следите за потерями пакетов и повторными отправками (retransmits).

USE Method: Проверяйте Утилизацию, Насыщение и Ошибки для каждого компонента.

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

Анализ ошибок, уровень успешных запросов и поиск точки насыщения

Мы подошли к экватору нашего курса. В предыдущих лекциях мы научились измерять скорость (время отклика), объем работы (пропускную способность) и цену этой работы (утилизацию ресурсов). Казалось бы, у нас есть все данные для оценки системы. Но представьте ситуацию: ваш сайт работает молниеносно, серверы холодные, но каждому пользователю вместо страницы товара показывается белый экран с надписью «Что-то пошло не так».

С точки зрения метрик времени и ресурсов — всё отлично. С точки зрения бизнеса — это катастрофа.

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

Метрики надежности: Error Rate

Error Rate (Уровень ошибок) — это доля запросов, завершившихся неудачей, по отношению к общему количеству запросов. Это индикатор здоровья системы. Если время отклика — это «пульс», то уровень ошибок — это «температура». Высокая температура говорит о воспалительном процессе.

Формула расчета уровня ошибок выглядит так:

Где: * — уровень ошибок в процентах. * — количество запросов, завершившихся ошибкой. * — общее количество отправленных запросов.

Например, если вы отправили 5000 запросов, и 25 из них упали:

Где: * — итоговый уровень ошибок.

Какие бывают ошибки?

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

Сетевые ошибки (Network Exceptions): Запрос даже не дошел до сервера или ответ не вернулся. Примеры: Connection Refused, Socket Timeout, DNS Lookup Failed. Это часто указывает на проблемы с балансировщиком нагрузки или перегрузку сетевого канала.

HTTP-ошибки (Server Side Errors): Сервер принял запрос, но не смог его обработать. Это коды состояния 5xx (500, 502, 503, 504). Это крик о помощи от вашего бэкенда: «Я перегружен» или «У меня упала база данных».

Функциональные ошибки (Assertion Failures): Самый коварный тип. Сервер возвращает код 200 OK (Всё хорошо), но в теле ответа приходит сообщение {"error": "Out of stock"} или пустая страница. Инструмент тестирования (JMeter, Gatling) по умолчанию посчитает такой запрос успешным. Чтобы ловить такие ошибки, нужно использовать Assertions (проверки содержимого ответа).

!Распределение типов ответов сервера во время нагрузочного теста.

Уровень успешных запросов (Success Rate)

Это обратная сторона медали. Если Error Rate показывает процент неудач, то Success Rate показывает процент успеха.

Где: * — уровень успешных запросов. * — уровень ошибок.

Эта метрика часто используется в SLA (Service Level Agreement). Например, требование «Доступность 99.9%» означает, что допустимый уровень ошибок составляет не более 0.1%.

> «В мире высокой нагрузки 99% успеха — это плохо. При 1000 запросах в секунду 1% ошибок означает, что 10 пользователей каждую секунду получают отказ. За час это 36 000 недовольных клиентов».

Точка насыщения (Saturation Point)

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

В тестировании производительности мы ищем момент, когда система «лопнет» или перестанет эффективно работать. Этот момент называется Точкой насыщения.

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

Обычно мы строим график зависимости Пропускной способности (RPS) от Количества пользователей (Concurrency).

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

Точка насыщения (The Knee): Мы добавляем пользователей, но RPS перестает расти или растет очень медленно. График изгибается. В этот момент один из ресурсов (CPU, Диск, Пул соединений к БД) утилизирован на 100%.

Зона деградации (Buckling Zone): Мы продолжаем добавлять пользователей. RPS начинает падать, а время отклика взлетает вертикально вверх. Начинают появляться ошибки (Timeouts).

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

Математика очередей

Почему после точки насыщения время отклика растет, даже если RPS не падает? Вспомним Закон Литтла, о котором мы говорили в первой лекции:

Где: * — среднее время отклика (Wait time). * — количество запросов в системе (очередь + обработка). * — пропускная способность (RPS).

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

Посмотрите на формулу: если числитель растет, а знаменатель не меняется, то результат (время отклика) обязан расти.

Стратегия поиска проблем

Когда вы анализируете результаты теста, следуйте этому алгоритму, чтобы связать ошибки, насыщение и ресурсы воедино:

1. Найдите момент начала ошибок

Посмотрите на график ошибок во времени. В какой момент они появились? * Если ошибки есть с самого начала (при минимальной нагрузке) — проблема в конфигурации или коде, нагрузка ни при чем. * Если ошибки появились на 10-й минуте теста при достижении 500 пользователей — это проблема производительности.

2. Сопоставьте с графиком Latency

Растут ли ошибки синхронно с ростом времени отклика? * Да: Скорее всего, это Timeouts. Система тормозит настолько, что клиенты (или балансировщик) разрывают соединение, не дождавшись ответа. * Нет: Время отклика низкое, но летят ошибки 500. Это значит, что сервер «падает быстро» (Fail Fast). Возможно, закончилась память или упал процесс базы данных.

3. Проверьте ресурсы (USE Method)

Посмотрите на графики мониторинга в момент появления ошибок. * CPU 100%? Очередь запросов скопилась, процессор не успевает. * Memory закончилась? Возможно, сработал OOM Killer (Out Of Memory Killer) и убил процесс приложения. * Диск перегружен? База данных встала в блокировку, ожидая записи на диск.

Fail Fast vs Hang

Что лучше для пользователя: увидеть ошибку мгновенно или смотреть на крутящийся спиннер загрузки 60 секунд?

В инженерии принято считать, что стратегия Fail Fast (Быстрый отказ) лучше. Если система перегружена, она должна честно и быстро ответить кодом 503 (Service Unavailable), чтобы балансировщик мог перенаправить запрос на другой сервер или чтобы клиент мог повторить попытку позже.

Худший сценарий — это Hang (Зависание). Зависший запрос держит соединение открытым, занимает память и поток процессора. Если таких запросов много, они вызывают цепную реакцию («эффект домино»), которая может положить весь кластер серверов.

Резюме

Error Rate — критическая метрика качества. Следите не только за кодами 5xx, но и за функциональными ошибками внутри 200 OK.

Точка насыщения — это предел возможностей вашей системы. После этой точки рост нагрузки приводит только к росту очередей и времени отклика.

Закон Литтла объясняет, почему после насыщения время отклика растет линейно или экспоненциально при фиксированном RPS.

Корреляция — ваш главный инструмент. Накладывайте графики ошибок, времени отклика и утилизации ресурсов друг на друга, чтобы найти первопричину сбоя.

Теперь у вас есть полный набор инструментов для проведения и анализа тестов. Но как представить эти данные бизнесу, который не хочет слышать про перцентили и утилизацию CPU? В следующей, заключительной части курса мы поговорим о составлении отчетов и визуализации результатов.