Воспроизводимое тестирование производительности

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

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

Ключевые факты

Минимальный набор для публикации
Вопрос, окружение, команда, длительность, повторы, дата и исходные результаты
Правило сравнения
Используйте одинаковую конфигурацию VPS, образ, версию инструмента и окно теста
Честная сводка
Сохраняйте медленные и неудачные запуски; сообщайте медиану и изменчивость
Граница безопасности
Ограничивайте потребление ресурсов и соблюдайте лимиты провайдера и сети

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

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

Укажите тариф и регион VPS, длительность, параллелизм, объём данных, соотношение чтения и записи, размер блока, протокол, удалённую точку и временное окно. Производительность общего хоста и интернет-маршруты могут меняться, поэтому тест — датированная выборка при заявленных условиях, а не постоянная гарантия.

  • Запишите решение и порог до начала.
  • По возможности испытывайте транзакцию уровня приложения.
  • Не объединяйте несвязанные оценки в один непрозрачный рейтинг.

Записывайте достаточно контекста для повторения запуска

Зафиксируйте тариф, регион, время выдачи, образ операционной системы, ядро, представление CPU, память, swap, устройства хранения, файловую систему, параметры монтирования, семейство IP и версии тестов. Полезные команды инвентаризации: lscpu, free -h, lsblk и uname -r. Перед публикацией удалите клиентские секреты и уникальные идентификаторы.

Отметьте, был ли сервер выдан только что, предварительно прогрет, недавно изменён или выполнял другую нагрузку. Запишите время начала с чётким часовым поясом и обслуживание провайдера. Для сетевых тестов определите обе конечные точки, их сети, направление, протокол и значимые ограничения скорости. Одной подписи «город — город» недостаточно для воспроизводимости.

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

Проводите ограниченные тесты CPU, хранилища и сети

Для CPU выберите инструмент вроде sysbench и укажите число потоков и длительность. Для хранилища fio может моделировать последовательный или случайный доступ, глубину очереди, размер блока, прямой ввод-вывод, размер файла и соотношение чтения и записи; сохраняйте машиночитаемый результат с --output-format=json. Убедитесь, что тестовый файл достаточно велик для вопроса, и объясняйте влияние кэша, а не объявляйте один режим универсально верным.

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

  • Используйте отдельный тестовый VPS без клиентской нагрузки.
  • Для публикуемых сравнений повторяйте одинаковую последовательность не менее пяти раз.
  • Сохраняйте вывод команд, ошибки и код завершения каждого запуска.

Показывайте изменчивость, а не скрывайте её

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

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

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

Публикуйте вместе методику, исходные данные и ограничения

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

Планируйте повторение после существенных изменений инфраструктуры или образа и сохраняйте прежние результаты с исходными датами. Исправления должны оставаться видимыми. Шаблон прозрачности VPSEverywhere.com исключён из индексации, пока содержит значения-примеры; операционными доказательствами можно представлять только реальные измерения, прошедшие заявленную процедуру проверки.

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

Источники

  1. Документация fio
  2. ESnet — документация iperf3
  3. IETF RFC 2681 — метрика задержки туда и обратно для IPPM
Частые вопросы

Частые вопросы

Какой тест VPS лучший?

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

Сколько запусков теста следует публиковать?

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

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

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

Можно ли запускать `fio` или `iperf3` на рабочем сервере?

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