Тестирование производительности VPS: latency и throughput

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

Главные метрики, которые стоит держать в фокусе, — latency и throughput. latency отражает время ожидания (задержка отклика), throughput показывает пропускную способность (сколько полезной работы вы завершаете за единицу времени). Для веба и API чаще важнее latency на хвостах распределения (p95/p99), для фоновых задач — throughput, но с оглядкой на стабильность.

latency и throughput: базовая терминология

Latency обычно измеряют как время от начала операции до её завершения. Для сети это время прохождения пакета и время ответа приложения; для диска — время выполнения I/O-операции; для CPU — задержка в очереди задач при перегрузке.

Throughput — это сколько данных или операций вы делаете за секунду. В сети throughput выражают как бит/сек или байт/сек; в дисках — как IOPS и MB/s; в вычислениях — как число итераций или операций в секунду, в зависимости от бенчмарка.

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

Четкие цели теста: что сравниваем

Перед стартом ответьте на три вопроса:

• С чем сравниваете: два провайдера, два региона, два тарифа, или “после смены диска/сети”?
• Какой тип нагрузки важен: CPU-bound, I/O-bound, network-bound или смешанный?
• Какие показатели критичны: среднее, p95/p99, время прогрева, стабильность на интервале, устойчивость к пиковым запросам?

Если цель — выбор между VPS для сервиса, то сравнивайте не “максимум”, а поведение при рабочей нагрузке. Если цель — диагностика проблем, то сравнивайте “до и после” и фиксируйте параметры окружения.

Подготовка к тестированию: окружение, контроль переменных

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

Факторы влияния: CPU, I/O, сеть, виртуализация

На виртуальной машине чаще всего влияет следующее:

• CPU scheduling: насколько предсказуемо выделяется время процессора для ваших потоков.
• Ограничения диска: реальные IOPS и latencies зависят от профиля (sequential или random), глубины очереди и размера блока.
• Сетевая подсистема: скорость и задержка могут меняться по направлению трафика и при росте параллелизма.
• Кэширование: “быстрый ответ” может быть результатом page cache, а не реальной скорости диска.
• Нагрузки на хосте: у соседей может быть своя пиковая активность, и вы увидите скачки.

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

Подготовка системы: обновления, энергосбережение, ядро

Перед тестами выполните базовую стабилизацию:

• Обновите пакеты и зафиксируйте версию ОС, чтобы одинаково интерпретировать результаты.
• Убедитесь, что вы используете один и тот же набор инструментов и их версию.
• Отключите лишние фоновые сервисы, которые могут добавлять нагрузку или сетевой трафик.
• Если нужно, проверьте частоты CPU и политику энергосбережения (на практике полезно хотя бы убедиться, что система не “усыпляет” CPU при простое).

Также стоит прогреть сервис: для сети и диска первые секунды часто не похожи на устойчивое состояние из‑за кэширования и установления очередей.

Инструменты: что собирать параллельно с бенчмарком

Сами бенчмарки дают “что”, а системная телеметрия помогает понять “почему”. Минимальный набор:

• Нагрузка CPU: mpstat или аналог (sysstat), чтобы видеть загрузку и простои.
• Дисковая активность: iostat (IO wait, MB/s, util), плюс журнал/статистика по ошибкам при необходимости.
• Память: vmstat и free, чтобы отслеживать своп и давление на RAM.
• Сеть: sar -n DEV или аналоги, плюс tcpdump/ss при сложных сетевых проблемах.

Из утилит для нагрузок:

• CPU/память: sysbench, stream (для памяти), stress-ng.
• Диск: fio.
• Сеть: iperf3 (часто лучше, чем “вручную гонять ping”).
• Трафик на уровне приложения: wrk, hey, k6, либо собственный нагрузочный клиент.

Если тестируете latency приложения, собирайте тайминги по каждому запросу и храните распределение, а не только среднее.

Бенчмарки CPU и памяти: что показывают и чего не показывают

CPU-бенчмарки и бенчмарки памяти полезны для грубой оценки и проверки гипотез, но редко полностью отражают работу реального сервиса. Причина простая: приложение может быть ограничено не вычислениями, а синхронизацией, I/O ожиданиями или сетевой задержкой.

Примеры: sysbench, stream, stress-ng

Для CPU подойдут:

• sysbench cpu test (фиксируем количество потоков и продолжительность).
• stress-ng для выявления “пределов” и проверки стабильности, но результаты лучше интерпретировать осторожно.

Для памяти часто используют:

• stream (проверяет пропускную способность и задержки памяти на типовых паттернах).

Ключевое — не гонять бенчмарк в одной конфигурации. Повторите тесты с разным числом потоков и зафиксируйте точную конфигурацию: сколько потоков, сколько минут, какие параметры компиляции (если сборка нужна), какие версии бинарников.

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

Практическое правило: сравнение между VPS имеет смысл, когда вы повторяете одинаковый тест и одинаковый профиль нагрузки. Если один VPS показывает выше throughput в тесте памяти, но ваш сервис упирается в дисковые операции, то вывод “там лучше” будет неверным.

Еще один момент — стабильность. Если производительность “скачет” из-за планировщика или конкуренции на хосте, среднее может выглядеть прилично, а на хвостах latency вы увидите проблемы.

Полезно фиксировать:

• среднее и медиану результата,
• дисперсию между запусками,
• наличие длительных провалов.

Типичные ошибки

Вот частые промахи при тестировании CPU:

• Разные версии ядра или разные лимиты контейнера/системы между сравнениями.
• Тест одним потоком, хотя ваш сервис использует много потоков.
• Недостаточная продолжительность теста: вы ловите случайный момент, а не режим.
• Игнорирование фоновых процессов, которые “слегка” нагружают CPU и дают эффект плавающих результатов.

Если вы видите “странно ровные” цифры, проверьте, не подменили ли вы среду тестом без реального доступа к диску или сеть стала слишком “комфортной” из‑за близкого тестового хоста.

Тестирование дисковой подсистемы: fio, iostat и профили IOPS

Диск — частый источник разочарований в VPS. Даже когда в документации пишут “быстрый SSD”, фактические latencies и IOPS зависят от очереди запросов, размера блока, типа доступа (random/sequential) и того, как включено кэширование.

Настройка fio под ваш сценарий

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

• Тип операций: read, write, rw, randread/randwrite.
• Размер блока: block size часто критичен для random-доступа.
• Количество потоков и глубину очереди (iodepth/numjobs).
• Продолжительность прогрева и измерения (warmup и runtime).
• Как вы хотите обойти кэш: в некоторых задачах полезно тестировать “почти без кэш-эффекта”, но это делается осознанно.

Практический подход:

• Сначала сделайте “быстрый профиль” чтение/запись и сравните порядок величин.
• Затем повторите тесты с параллелизмом, близким к вашему реальному паттерну.
• Наконец, проверьте хвосты latency: fio показывает распределение, а вам важно не только среднее.

Sequential vs random, queue depth и размер блока

Для последовательного чтения вы обычно увидите throughput (MB/s). Для случайного доступа важны IOPS и latency на маленьких блоках. В реальных системах случайный профиль почти всегда сложнее предсказуем по хвостам.

Queue depth (глубина очереди) влияет на то, как диск “подаётся” планировщику. При малой очереди вы можете недооценить пропускную способность, а при большой — упереться в внутренние ограничения и получить рост latency.

Поэтому сравнение провайдеров должно учитывать одинаковые параметры очереди. Иначе вы сравните разные “режимы работы” диска.

Как выявлять bottleneck и кэширование

Чтобы понять, где ограничение, смотрите на iostat и метрики приложения:

• Если IO wait растет и CPU при этом не загружен, узкое место почти наверняка дисковое ожидание.
• Если throughput высокий, но latency приложения плохая, возможно, проблема в очередях на уровне ОС/приложения или в синхронизации.
• Если fio показывает “очень быстрые” ответы после нескольких минут, проверьте, не сработало ли кэширование. В таком случае тест нужно перестроить, чтобы оценить именно реальную нагрузку.

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

Тестирование сети: latency, jitter и throughput

Сеть часто задаёт границы даже там, где диск и CPU “вроде бы справляются”. Если ваш сервис общается с базой, хранением, внешними API или просто активно отдаёт контент, вы упрётесь либо в latency, либо в throughput, либо в их комбинацию.

Метрики и методика измерения latency

Для сети важно различать:

• ping latency: отражает задержку ICMP, но не всегда коррелирует с прикладным поведением.
• latency на уровне TCP/UDP: зависит от маршрутизации, обработки пакетов и буферов.
• jitter: разброс задержек, который может ухудшать качество и снижать предсказуемость.

Практический подход:

• Сначала соберите baseline ping и трассировку маршрута к тестовому узлу.
• Затем измерьте прикладной latency (через HTTP/TCP запросы, или через echo-сервис/скрипт на своём клиенте).
• И только потом делайте throughput тесты, потому что при перегрузке канала latency обычно растёт, а throughput “упирается” в ограничения.

Если вам нужны p95/p99 latency, не используйте только среднее время ping. Снимайте распределение с вашего приложения или хотя бы с сервиса, который имитирует ваш запросный паттерн.

iperf3: TCP и UDP, parallel streams

iperf3 удобен для проверки пропускной способности и поведения соединения. Но iperf3 измеряет “канал” между двумя точками, а не ваш реальный сценарий. Поэтому используйте его как инструмент диагностики.

Что обычно делают:

• TCP тесты для оценки устойчивого throughput.
• UDP тесты для оценки пакетов при заданной частоте и сравнения потерь/джиттера.
• Повторение с разным числом потоков (parallel streams), если ваш сервис открывает много соединений или работает параллельно.

При интерпретации данных важно помнить: “максимальный” throughput может достигаться при одном режиме буферов и не достигаться при реальной нагрузке, где запросы прерывистые и зависят от таймаутов.

ping vs реальный трафик: как не попасть в ловушку

Частая ловушка — использовать ping как единственный критерий “быстро/медленно”. Ping измеряет конкретный тип трафика и может не отражать реальную производительность TCP при вашей нагрузке. Также ping может идти по одному пути маршрутизации, а ваш прикладной трафик — по другому.

Если вы оцениваете VPS для веба или API, подключите нагрузочный тест уровня HTTP: wrk/hey/k6 и снимайте latency распределения. Это более честная проверка.

Типичные ошибки и артефакты

Ошибки, которые встречаются регулярно:

• Тест в часы пикового трафика, без повторов в другое время.
• Односторонняя проверка: провайдер может иметь нормальную загрузку в одном направлении, но слабую в другом (зависит от маршрутизации).
• Сравнение “абсолютных максимумов” без одинаковых сетевых условий (разные тестовые клиенты, разные регионы, разные времена).
• Неправильный масштабирование параллелизма: один VPS может выдерживать больше соединений, но при неудачных настройках вы “недогрузите” оба и получите обманчивый вывод.

Если вы заметили всплески latency без роста нагрузки в системе, проверьте сетевые буферы и возможные потери пакетов. Иногда проблема не в VPS, а в пути к точке теста.

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

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

Нагрузочные сценарии для веба и API

Для веба и API используйте инструменты, которые:

• поддерживают нужный протокол (HTTP/1.1, HTTP/2 при необходимости),
• позволяют задать RPS или число параллельных запросов,
• собирают latency по каждому запросу.

Хорошая практика — сравнивать не только throughput (сколько запросов в секунду), но и время ответа на хвостах. Именно хвосты чаще приводят к проблемам пользователей: время ожидания растёт, ретраи усиливают нагрузку, и система “сыпется” каскадно.

Полезно разделить сценарии:

• “Лёгкая” нагрузка (чтобы увидеть базовую latency).
• “Рабочая” нагрузка (похожа на ваш планируемый режим).
• “Пограничная” (где начинается рост задержек и отказоустойчивость включается в работу).

Базы данных и очереди запросов

Если вы запускаете тесты для VPS под базу (PostgreSQL, MySQL и т.п.), то “диск отдельно” и “приложение отдельно” могут не совпасть с реальностью. Причина — блокировки, кэш на уровне СУБД, фоновые операции, поведение планировщика запросов.

Поэтому при тестах баз данных:

• повторяйте типичный запросный профиль (не только простые выборки),
• используйте одинаковые индексы и настройки,
• фиксируйте планировщик и статистику, чтобы избежать “сюрпризов” между запусками.

Даже если вы не сможете полностью воспроизвести прод, вы можете построить воспроизводимый стресс на ваших паттернах и сравнить хвосты latency.

Как собрать профиль: p95/p99 и время ответа

Для выбора VPS и диагностики лучше всего работает простой протокол сбора:

• записывать latency распределение (p50, p95, p99, max),
• учитывать долю ошибок (timeouts, 5xx),
• отслеживать корреляцию с загрузкой CPU, диском и сетью.

Если p95 растёт быстрее среднего, это признак очередей. Если p99 скачет, но среднее остается стабильным, иногда виноваты периодические задачи (сбор статистики, миграции, GC, бэкапы) или сетевые “провалы”.

План тестов: от быстрых проверок до регламентов

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

Минимальный набор измерений за 30–60 минут

Если вы хотите оценить VPS перед тем, как переносить сервис, подойдет такой набор:

• CPU: sysbench CPU (несколько потоков, короткий runtime).
• Память: stream или аналогичный быстрый тест пропускной способности.
• Диск: fio для sequential read и random read на типовых размерах блока.
• Сеть: iperf3 TCP на разумной длительности, плюс проверка latency приложения (например, HTTP-echo или ваш endpoint).
• Телеметрия: iostat и показатели CPU во время тестов.

Смысл этого пакета — увидеть, есть ли “критические несоответствия” вашему профилю. Если базовая дисковая random-составляющая слишком слабая, дальнейшие тонкие сравнения могут быть бессмысленны.

Расширенный протокол для сравнения провайдеров

Для сравнения двух VPS как минимум сделайте:

• Повторяемость: несколько запусков одного и того же набора тестов в одинаковой конфигурации.
• Контроль времени: тестируйте в похожие часы (или хотя бы одинаковые временные окна).
• Несколько уровней параллелизма: один поток и режим ближе к вашему реальному.
• Хвосты latency: обязательно p95/p99 для сетевых/приложенческих тестов.
• Сбор “почему”: параллельно логируйте iostat, CPU и ошибки сети.

Если сравниваете провайдеров, фиксируйте также географию, тип образа ОС и версию ядра. Иногда проблема не в “силе тарифа”, а в различиях в настройках и окружении.

Повторяемость: что фиксировать и как хранить логи

Чтобы результаты можно было пересмотреть через месяц:

• сохраняйте команды и параметры тестов (командная строка, переменные окружения),
• фиксируйте версии: ОС, fio/iperf3/sysbench, библиотеки (если влияет),
• храните логи метрик и сырые результаты бенчмарков,
• указывайте точку времени, длительность, число потоков и сетевой маршрут (хотя бы регион/адрес тестового узла).

Если вы ведёте заметки, заведите “паспорт теста”: что именно тестировали и как интерпретировали итог. Это сильно ускоряет будущие сравнения.

Интерпретация результатов и принятие решений

После тестирования наступает этап, где многие ошибаются: берут один график и делают вывод о “лучшем VPS”. Производительность VPS — это набор компромиссов, и разные части системы ограничивают друг друга в разное время.

Когда производительность растет, но SLA не улучшается

SLA по сервису чаще завязано на latency и ошибки, а не на абсолютный throughput в тестовой петле. Поэтому возможно, что VPS “быстрее” по throughput, но приложение всё равно получает задержки из‑за очередей на уровне базы или сетевой деградации при росте параллелизма.

Проверяйте:

• рост p95/p99 при увеличении нагрузки,
• увеличение доли ошибок,
• наличие резких провалов (например, периодический лаг GC/IO flush/фоновые операции).

Если throughput растёт, но хвосты не улучшаются, вам выгоднее тот VPS, который стабильнее на рабочем диапазоне, а не тот, который “максимальный в вакууме”.

Разница между номинальными и фактическими бенчмарками

Рекламные цифры и маркетинговые “бенчмарки” могут быть получены в других режимах: другой блок, другой размер очереди, другой тестовый клиент, другой маршрут сети. Даже тесты от провайдера часто не совпадают с вашей реальностью.

Поэтому сравнивайте фактические результаты:

• на вашем профиле (или максимально близком),
• при сопоставимых параметрах параллелизма,
• по хвостам latency и ошибкам, если тестируете сервис.

Выбор VPS по вашему профилю нагрузки

Практичный ориентир:

• CPU-bound приложения: важно стабильное время ответа, минимальная деградация при росте числа потоков, корректная настройка CPU scheduling.
• I/O-bound: ключевое — random I/O, p95/p99 latency диска и предсказуемость при очередях.
• Network-bound: смотрите не только пропускную способность, но и latency на реальном прикладном протоколе, а также jitter и потери.
• Смешанная нагрузка: делайте комбинированные сценарии и смотрите корреляцию метрик, чтобы определить, что именно ограничивает производительность.

Если ваша система чувствительна к таймаутам, то “чуть быстрее” не всегда равно “лучше”. Иногда важнее стабильность, чем пики.

Заключение: как превратить бенчмарки в решение

Тестирование производительности VPS работает, когда вы измеряете не “в общем”, а под конкретный сценарий. Делайте акцент на latency и throughput, проверяйте диск и сеть разными профилями, а для сервиса обязательно смотрите хвосты времени ответа и долю ошибок.

Перед покупкой или миграцией используйте простой порядок:

• Сформулируйте профиль нагрузки и выберите метрики: p95/p99 latency и throughput.
• Подготовьте окружение и зафиксируйте версии инструментов и конфигурации.
• Прогоните минимум: CPU, диск fio, сеть iperf3 и прикладной тест.
• Если результаты важны для решения — повторите с несколькими уровнями параллелизма и соберите iostat/CPU телеметрию.
• Сравнивайте не “лучший максимум”, а поведение на рабочем диапазоне и в условиях конкуренции.

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