Как провести тест производительности системы и корректно интерпретировать результаты

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

Один высокий показатель в бенчмарке не подтверждает, что система готова к рабочей нагрузке. Реальную границу возможностей определяют по связке throughput, latency, error rate и устойчивости во времени. Максимальная загрузка CPU или диска становится проблемой только тогда, когда одновременно растут задержки, очереди или число ошибок.

Для отдельных проверок можно использовать stress, sysbench, Apache Benchmark, fio и iperf3. Практические команды для базового тестирования серверов собраны в руководстве по нагрузочному тестированию серверов и кластеров. Ниже приведен общий протокол, который подходит для Linux, Windows, виртуальных машин, NAS, баз данных и контейнерных платформ.

Как провести тест производительности системы: краткий алгоритм

Рабочий алгоритм состоит из восьми шагов:

1. Сформулировать измеримую цель: например, выдержать 500 запросов в секунду при p95 latency не выше 200 мс.
2. Зафиксировать конфигурацию сервера, ПО, сети, хранилища, виртуализации и набор данных.
3. Проверить фоновые процессы, состояние кэшей, заполненность дисков и температуру оборудования.
4. Подготовить базовую линию, то есть повторяемый замер текущего состояния.
5. Описать рабочий и пиковый профиль нагрузки с числом параллельных операций и длительностью.
6. Отделить прогрев от измеряемого интервала.
7. Запустить несколько одинаковых прогонов и сохранить каждый результат вместе с логами.
8. Сопоставить throughput, latency, ошибки и потребление ресурсов, затем повторно проверить гипотезу об узком месте.

Такой порядок подходит и для проверки одного сервера, и для сравнения двух конфигураций. Для теста виртуальной машины в журнал добавляют сведения о гипервизоре, CPU steal и лимитах ресурсов. Для NAS или ZFS-пула фиксируют тип дисков, схему RAID, состояние кэшей, заполненность пула и режим синхронной записи.

Что должен показать результат теста

Результат должен отвечать на конкретный технический вопрос. Формулировка «проверить скорость сервера» слишком расплывчата. Подходящие варианты выглядят так:

• определить максимальный throughput веб-сервиса при p95 latency не выше 300 мс;
• узнать, сколько параллельных операций чтения выдерживает хранилище;
• сравнить базовую и новую конфигурации после замены дисков;
• проверить запас CPU и памяти перед увеличением числа контейнеров;
• найти нагрузку, при которой растет очередь диска или появляются ошибки приложения.

Для каждого вопроса заранее задают показатели успеха. Обычно это throughput, средняя latency, p95 и p99, error rate, время выполнения операции, загрузка ресурсов и длительность стабильного режима. Если система обслуживает пользователей, перцентили важнее среднего времени ответа: редкие задержки в несколько секунд могут быть критичными при хорошем среднем значении.

Короткий чек-лист достоверного замера

• Цель теста записана одним предложением и содержит измеримые критерии.
• Конфигурация сервера и версии ПО сохранены.
• Набор данных, размер файлов и состояние кэша описаны.
• Фоновые задачи остановлены или включены в профиль нагрузки.
• Нагрузчик по возможности работает на отдельном узле.
• Перед измерением выполнен прогрев.
• Каждый прогон имеет одинаковые параметры и длительность.
• Собраны временные ряды CPU, RAM, диска, сети и метрик приложения.
• Сохранены ошибки, логи, команда запуска и итоговые значения.
• Вывод подтвержден повторным прогоном.

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

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

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

Что зафиксировать до начала замеров

Создайте паспорт теста. Минимальный набор полей приведен в таблице.

В Linux базовую информацию удобно собрать командами:

uname -a
lscpu
free -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
ip -br link
systemd-detect-virt

Для Windows записывают версию системы, модель CPU, объем RAM, параметры дисков, сетевых адаптеров и виртуальной платформы. Счетчики Performance Monitor сохраняют вместе с результатом нагрузчика, чтобы потом сопоставить время ответа с состоянием ОС.

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

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

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

Проверьте температуру CPU, дисков и сетевых компонентов. Thermal throttling снижает частоту после прогрева и превращает короткий быстрый тест в длинный медленный. На виртуальных машинах фиксируют CPU steal, ballooning памяти и лимиты vCPU. Автоматическое масштабирование отключают для контрольного замера или записывают его правила и моменты изменения ресурсов.

Для изолированного стенда можно использовать отдельный облачный сервер с предсказуемой конфигурацией. Timeweb Cloud предоставляет VDS/VPS, хранилище, базы данных и Kubernetes, поэтому его можно рассматривать как площадку для временного нагрузчика или отдельной тестовой среды. Перед сравнением проверьте класс виртуальных ресурсов и сетевые ограничения, иначе результаты разных тарифов нельзя считать сопоставимыми.

Подготовка данных и состояния системы

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

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

Для дисков укажите свободное место и длительность работы. SSD может показать высокий результат в первые минуты, пока не исчерпан быстрый кэш записи. ZFS меняет поведение в зависимости от ARC, SLOG, recordsize, типа нагрузки и заполненности пула. Рабочее хранилище с синхронными записями нельзя оценивать по тесту последовательного чтения пустого тома.

Выбор сценариев нагрузки для тестирования

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

Базовая, рабочая и пиковая нагрузка

Подготовьте три профиля:

• Базовый: небольшое число операций, достаточное для проверки корректности инструмента и baseline.
• Рабочий: типичная нагрузка за обычный период, включая фоновые процессы и стандартное число пользователей.
• Пиковый: кратковременный или длительный рост запросов, который нужно выдержать без нарушения SLO.

Для каждого профиля задайте число параллельных операций, скорость поступления запросов, длительность и критерии остановки. Например, тест может включать 50, 100 и 200 параллельных клиентов, по 10 минут на уровень нагрузки, с условием p95 latency ниже 500 мс и error rate ниже 1%.

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

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

Сценарии для CPU и памяти

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

Следите за user, system, iowait, steal и частотой CPU. Одновременный рост system и latency может указывать на большое число системных вызовов или сетевую обработку. Высокий iowait означает ожидание операций ввода-вывода, а не нехватку вычислительных инструкций.

Для памяти проверяют рост RSS процессов, page cache, available RAM, swap in/out, major page faults и события OOM. Тест должен длиться достаточно долго, чтобы выявить утечку или постепенное заполнение памяти. Объем набора данных подбирают так, чтобы проверить рабочий режим, но не вызвать OOM случайным превышением лимита.

В контейнерах отдельно смотрят лимит памяти и фактический working set. Хост может иметь свободную RAM, пока контейнер уже упирается в cgroup limit. Для виртуальной машины аналогичная ситуация возникает при малом объеме vRAM, ballooning или активном свопинге на уровне гостевой ОС.

Сценарии для диска и сети

Дисковая нагрузка должна описывать:

• последовательный или случайный доступ;
• чтение, запись или заданное соотношение read/write;
• размер блока, например 4 KiB, 64 KiB или 1 MiB;
• глубину очереди и число потоков;
• синхронные или асинхронные операции;
• рабочий объем данных, который помещается или не помещается в кэш.

Высокая последовательная скорость не означает хорошую работу базы данных. База может выполнять случайные операции блоками 8 KiB и ждать подтверждения каждой записи. Для проектирования СХД полезно сопоставлять IOPS, throughput и latency, как описано в руководстве по расчету производительности СХД.

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

Для сети проверяют throughput, RTT, jitter, packet loss и retransmits. Один поток может не заполнить канал с высокой задержкой, поэтому тест повторяют с несколькими потоками и сравнивают результат с прикладной передачей данных.

Как организовать повторяемый замер производительности системы

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

Прогрев и длительность прогона

Прогрев нужен, когда поведение системы меняется после старта. Это происходит при заполнении page cache, прогреве ARC, создании пула соединений, компиляции JIT-кода, загрузке индексов и выходе диска на рабочую температуру.

Измерительный интервал начинают после переходной фазы. Например, первые 5 минут можно отвести на прогрев, следующие 15 минут использовать для оценки steady state. Для проверки утечки памяти, накопления очередей и throttling тест продлевают до 30-60 минут или дольше.

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

Сколько раз повторять тест

Для первичного сравнения проводят минимум 3-5 одинаковых измерительных прогонов. Каждый результат сохраняют отдельно. Среднее значение используют осторожно, потому что один выброс может изменить его сильнее, чем медиану.

В таблицу заносят медиану, минимум, максимум и перцентили latency. Для throughput полезно хранить среднее за измерительный интервал и значения по временным окнам, например за каждую минуту. Разброс 2% и разброс 30% требуют разных выводов даже при одинаковой медиане.

Причины выброса записывают рядом с результатом: обновился кэш, сработал backup, изменился частотный режим CPU, произошел сетевой retransmit или нагрузчик потерял соединение. Удалять плохой прогон без объяснения нельзя.

Какие данные сохранять

• цель и критерий успеха;
• команду запуска или файл конфигурации инструмента;
• время начала и окончания, часовой пояс, длительность прогрева;
• версии ОС, ядра, драйверов, приложения и тестового инструмента;
• параметры нагрузки и набор данных;
• метрики CPU, RAM, диска, сети и гипервизора;
• логи приложения, коды ошибок и системные события;
• итоговые значения каждого прогона и зафиксированные отклонения.

Для длительных тестов сохраняйте временные ряды. Итог «p95 равен 180 мс» не показывает, был ли сервис стабильным все 20 минут или последние 5 минут он уже накапливал очередь.

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

Инструменты и сбор метрик во время нагрузочного теста системы

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

Системные метрики Linux и Windows

Для Linux подходят стандартные утилиты:

• vmstat 1 показывает процессы, память, swap, прерывания, контекстные переключения и CPU;
• iostat -xz 1 помогает оценить throughput, await, очередь и загрузку устройств;
• pidstat -dur 1 показывает CPU, память и ввод-вывод отдельных процессов;
• sar -n DEV 1 собирает сетевую активность по интерфейсам;
• free -h помогает разделить available RAM, свободную память и кэш;
• ss -s показывает состояние TCP-соединений и признаки накопления очередей;
• журналы ядра позволяют проверить OOM, ошибки диска, сетевые сбои и throttling.

vmstat 1
iostat -xz 1
pidstat -dur 1
sar -n DEV 1
free -h
ss -s

Для Windows используют Performance Monitor с логированием счетчиков CPU, памяти, дисков, сетевых интерфейсов и процессов. Важен интервал сбора, например 1 или 5 секунд. Один снимок после завершения теста скрывает момент, когда ресурс достиг предела.

Метрики приложения и виртуализации

На уровне приложения собирают RPS, число операций в секунду, время ответа, p95/p99, коды ошибок, таймауты, длину очередей и состояние пула соединений. Для базы данных добавляют активные запросы, блокировки, cache hit ratio и время выполнения ключевых запросов.

В контейнерах проверяют CPU throttling, memory limit, OOMKilled, сетевые лимиты и статистику cgroups. В виртуальной машине смотрят CPU steal, ballooning, дисковую задержку на уровне гостя и хоста. Низкая загрузка CPU внутри гостя не доказывает наличие запаса, если vCPU долго ждет физический процессор.

Нагрузчик по возможности размещают на отдельном сервере. Иначе он конкурирует с приложением за CPU, RAM, диск и сеть. Для теста распределенной системы фиксируют метрики всех узлов, а не только машины, на которую направлен трафик.

Как читать результаты теста по CPU, памяти, диску и сети

Анализ строят по цепочке: нагрузка, throughput, latency, ошибки, ресурсное состояние. Такой порядок помогает отличить насыщение от побочного эффекта. Средняя загрузка ресурса без контекста редко дает полезный вывод.

CPU: загрузка, распределение по ядрам и steal time

Разделяйте user, system, iowait и steal:

• user показывает время приложения и пользовательских процессов;
• system отражает работу ядра, системные вызовы и обработку ввода-вывода;
• iowait указывает время ожидания операций ввода-вывода;
• steal показывает, сколько времени виртуальная машина ждала CPU гипервизора.

Общая загрузка 70% может скрывать одно полностью занятое ядро и несколько свободных. Это характерно для однопоточного приложения, блокировок и неравномерного распределения IRQ. Смотрите загрузку отдельных ядер, частоту CPU и изменение throughput при увеличении параллелизма.

Признак вычислительного предела: throughput перестает расти, latency увеличивается, а user или system стабильно близки к насыщению. Признак проблемы виртуализации: растет steal time, хотя внутри гостя остается видимый запас CPU. Высокий iowait требует проверки диска и сети, а не немедленной замены процессора.

Linux load average нельзя читать как процент CPU. В показатель входят runnable-задачи и процессы в непрерываемом ожидании, часто связанном с диском. Load average 8 на восьмиядерной системе может означать полную загрузку CPU, но при высоком iowait тот же показатель отражает очередь ввода-вывода.

Память: свободный RAM, кэш, swap и OOM

Поле free не равно запасу памяти. Linux использует свободную RAM для page cache, поэтому важнее смотреть available, размер кэша, RSS процессов и динамику swap.

Нормальный кэш ускоряет повторное чтение и может уменьшать нагрузку на диск. Проблема начинается при устойчивом снижении available RAM, росте swap in/out, major page faults и увеличении latency. События OOM в журнале подтверждают принудительное завершение процессов из-за нехватки памяти.

Связывайте память с диском. Активный swap увеличивает дисковую очередь и задержки, а рост page cache может временно улучшить тест чтения. Если после увеличения набора данных throughput резко падает, вероятна зависимость от кэша, а не универсальный прирост производительности диска.

Диск: IOPS, throughput, latency и очередь

IOPS показывают число операций в секунду. Throughput показывает объем переданных данных. Latency отражает задержку одной операции. Эти показатели зависят от размера блока: 100 000 операций по 4 KiB и 100 000 операций по 1 MiB создают разный поток данных.

Смотрите на await, глубину очереди, read/write-профиль и загрузку устройства. Рост очереди вместе с latency и остановкой throughput указывает на насыщение. Высокий util полезен как сигнал активности, но для современных SSD его нельзя трактовать как универсальный порог: важны тип операций, параллелизм и хвост задержек.

Синхронная запись, RAID, ZFS, журналирование и кэш контроллера меняют результат. Синтетический тест может обходить часть прикладного пути или работать с объемом, который полностью помещается в RAM. При проверке базы данных или NAS повторяйте профиль приложения: случайные блоки, смешанное чтение и запись, реальные размеры файлов и нужный уровень параллелизма.

Сеть: пропускная способность, задержка и потери

Пропускная способность без задержки не описывает качество канала. Для каждого прогона записывают throughput, RTT, jitter, packet loss, retransmits, загрузку интерфейса и число потоков.

Потери пакетов даже на небольшом уровне могут резко увеличить latency TCP из-за повторной передачи. Высокий RTT ограничивает результат одного потока, поэтому многопоточный тест может показать больший throughput. Это не означает, что прикладной сервис получит такую же скорость.

Сопоставляйте сетевой бенчмарк с рабочим протоколом. TLS, VLAN, MTU, firewall, шифрование, компрессия и удаленное хранилище меняют CPU и задержки. Если интерфейс загружен на 40%, а приложение отвечает медленно, причина может находиться в RTT, блокировках, сервере назначения или ограничении протокола.

Как определить узкое место и оценить производительность сервера

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

Признаки реального узкого места

Ищите четыре признака:

• ресурс устойчиво приближается к своему пределу;
• растет очередь или задержка обслуживания;
• throughput перестает увеличиваться или снижается;
• эффект повторяется при том же профиле нагрузки.

Примеры связок:

• высокий iowait, рост disk latency и очереди устройства, значит приложение ждет хранилище;
• swap in/out, major page faults и рост времени ответа, значит системе не хватает доступной памяти;
• высокий CPU steal и падение throughput внутри виртуальной машины, значит ограничение связано с гипервизором или конкуренцией за физический CPU;
• packet loss, retransmits и рост RTT при увеличении трафика, значит сетевой путь не выдерживает профиль;
• низкая загрузка ресурсов, длинная очередь в приложении и рост latency, значит ограничение может находиться в блокировках, пуле соединений или последовательном участке кода.

Низкая загрузка CPU не исключает узкое место. Процесс может ждать диск, сеть, mutex или свободное соединение. Высокая загрузка диска не всегда означает проблему, если latency остается стабильной, throughput растет, а SLO выдерживается.

Граница стабильной работы и запас производительности

Границу стабильной работы задают через SLO или SLA. Пример: система должна выдерживать 300 запросов в секунду в течение 30 минут при p95 latency не выше 250 мс, p99 не выше 700 мс и error rate ниже 0,5%.

Нагрузку увеличивают ступенчато, например на 25-50 запросов в секунду за шаг. На каждом уровне ждут установления стабильного режима и фиксируют throughput, latency, ошибки и метрики ресурсов. Предел наступает там, где нарушается критерий качества или начинается необратимое накопление очереди.

Запас производительности считают относительно рабочей и прогнозируемой пиковой нагрузки. Если стабильный предел равен 420 RPS, текущая пиковая нагрузка 300 RPS, запас по throughput составляет 120 RPS, или 40% относительно текущего пика. Такой запас нельзя заменять фразой «CPU свободен на 40%», потому что ограничителем может выступать диск, сеть или приложение.

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

Почему нельзя делать вывод по одной метрике

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

Поэтому заключение строят как проверяемую гипотезу: «при 250 RPS p95 вырос с 180 до 640 мс, одновременно disk await увеличился с 3 до 48 мс, очередь устройства выросла в 6 раз; повторный тест с меньшей интенсивностью возвращает значения к baseline». Такая запись сильнее утверждения «серверу не хватает диска».

Анализ результатов бенчмарка и сравнение конфигураций

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

Как сравнивать базовый и новый вариант

Используйте одинаковые:

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

Лучше выполнить серии baseline и нового варианта в чередующемся порядке, например A-B-A-B, если среда меняется со временем. Для длительных сравнений контролируйте температуру, частоту CPU, состояние SSD и внешнюю активность.

Какие изменения считать значимыми

Сравнивайте медиану и p95/p99, а не одно среднее число. Записывайте абсолютное изменение и относительный процент. Прирост throughput на 8% при разбросе между прогонами 12% нельзя считать доказанным улучшением без дополнительных повторов.

Проверяйте цену улучшения. Конфигурация может увеличить throughput на 20%, но одновременно поднять p99 latency, энергопотребление, число ошибок или стоимость ресурсов. Регрессия в хвосте задержек часто важнее небольшого прироста среднего результата.

Критерий успеха формулируют заранее. Например: «новая конфигурация должна увеличить устойчивый throughput минимум на 15% без роста p99 более чем на 10% и без увеличения error rate». Это снижает риск подгонки вывода под понравившуюся цифру.

Как оформить вывод для внедрения

Техническое заключение удобно писать по шаблону:

В сценарии чтения файлов при 120 параллельных клиентах новая конфигурация показала throughput 1,8 ГБ/с против 1,2 ГБ/с у baseline. Медиана latency снизилась на 14%, p99 остался в пределах прежнего диапазона. Ограничение сместилось с дисковой подсистемы на сетевой интерфейс, запас до заданного SLO составляет 25%. Конфигурация подходит для запуска при условии сохранения текущего профиля данных.

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

Типичные ошибки при тестировании производительности системы

Синтетический тест вместо рабочей нагрузки

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

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

Средние значения без перцентилей и временных рядов

Среднее latency может составлять 80 мс, когда 1% запросов регулярно выполняется за 2 секунды. Для пользовательского сервиса это заметная деградация, хотя среднее выглядит приемлемо.

Сохраняйте p95 и p99, график во времени и error rate. Временной ряд показывает короткий всплеск, постепенный рост очереди, завершение дискового кэша и переход CPU в throttling.

Неполная фиксация условий теста

Без точной команды, версии ПО и состояния данных повторить замер нельзя. В отчет добавляют параметры ядра, конфигурацию RAID или ZFS, сетевую схему, лимиты виртуализации, состояние кэшей, размер набора данных и фоновые задачи.

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

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

Шаблон отчета и итоговый чек-лист проверки производительности

Структура отчета о тестировании

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

Минимальная таблица результатов может выглядеть так:

Финальная проверка перед выводом

• Цель теста связана с рабочей операцией и содержит измеримый критерий.
• Baseline проверен несколькими прогонами.
• Стенд, версии ПО, данные и фоновые задачи записаны.
• Нагрузка соответствует обычному и пиковому режиму эксплуатации.
• Прогрев и измерительный интервал разделены.
• Сохранены результаты всех прогонов, а не только лучший показатель.
• В отчете присутствуют p95/p99, error rate и временные ряды.
• Метрики приложения сопоставлены с CPU, RAM, диском и сетью.
• Найденное узкое место подтверждено повторным тестом.
• Граница стабильной работы определена по SLO или SLA.
• Запас посчитан относительно реальной рабочей и пиковой нагрузки.
• Рекомендация содержит ограничения и условия повторной проверки.

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