Тестирование и бенчмарки

Что такое бенчмарк

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

Бенчмарки бывают трёх типов:

• Синтетические — искусственная нагрузка на конкретный узел: скорость диска, память, FLOPS видеокарты. Чистое сравнение железа, но слабо предсказывает поведение вашего приложения.
• Прикладные — реальная задача целиком: сборка проекта, инференс модели, обработка запросов. Ближе к жизни, хуже переносится между конфигурациями.
• Отраслевые наборы — MLPerf для ML-железа, TPC для баз данных: методика зафиксирована, результаты публикуются.

Чему бенчмарки не равны: маркетинговым цифрам вендора. Их получают в идеальных условиях на подобранной нагрузке. Для GPU это особенно заметно — заявленные TFLOPS достигаются на плотных матричных операциях нужной точности, а реальная задача упирается ещё и в пропускную способность памяти.

Как мерить честно:

• прогревайте систему — первые запросы медленнее из-за холодного кеша и JIT;
• запускайте несколько раз и смотрите разброс, а не одно значение;
• проверяйте, что упёрлись именно в то, что меряете (GPU-тест при 40% GPU utilization меряет что угодно, только не GPU);
• фиксируйте версии драйверов, библиотек и параметры — иначе замер невоспроизводим.

RPS: что это

RPS (Requests Per Second) — количество запросов, которые сервис успевает обработать за секунду. Основная метрика пропускной способности веб-сервисов и API. Синоним в контексте баз данных — QPS (Queries Per Second).

RPS связан с задержкой и параллелизмом:

RPS = число одновременных запросов / среднее время обработки

100 одновременных запросов × 200 мс на ответ  →  100 / 0,2 = 500 RPS

Отсюда неочевидное следствие: RPS сам по себе ничего не говорит о качестве сервиса. Можно показать 5000 RPS, если каждый ответ идёт 10 секунд, — формально пропускная способность высокая, фактически сервисом невозможно пользоваться. Поэтому RPS всегда смотрят вместе с задержкой и долей ошибок.

Про задержку смотрят не среднее, а перцентили:

Метрика	Что означает	Зачем
p50 (медиана)	Половина запросов быстрее	Типичный пользователь
p95	95% быстрее этого значения	Заметные тормоза
p99	99% быстрее	Худший опыт, часто пишется в SLA
avg	Среднее	Прячет выбросы, полезна редко

Среднее обманывает: при 99 ответах по 50 мс и одном на 5 секунд среднее — 100 мс, и всё выглядит прекрасно, хотя каждый сотый клиент ждал пять секунд.

Что такое нагрузочное тестирование

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

Виды:

Вид	Что делаем	Что выясняем
Load	Ожидаемая нагрузка	Держим ли обычный трафик
Stress	Наращиваем до отказа	Где предел и как именно ломается
Soak (endurance)	Средняя нагрузка часами	Утечки памяти, переполнение дисков
Spike	Резкий всплеск	Успеет ли autoscaling
Capacity	Ищем потолок при заданном SLA	Сколько серверов нужно

Пример на k6 — 100 виртуальных пользователей с порогами, по которым тест сам падает:

// запуск: k6 run --vus 100 --duration 60s script.js
export const options = {
  thresholds: {
    http_req_duration: ['p(95)<300'],   // 95% быстрее 300 мс
    http_req_failed: ['rate<0.01'],     // ошибок меньше 1%
  },
};

Что важно на практике:

• Тестируйте на конфигурации, похожей на боевую. Замер на ноутбуке не переносится на сервер.
• Генератор нагрузки не должен быть узким местом. Если 100% CPU у того, кто стреляет, вы измерили его, а не сервис.
• Смотрите, где упёрлись: CPU, диск, сеть, пул соединений к БД. Без этого результат — просто число.
• Стресс-тест интереснее нагрузочного: под перегрузом сервис должен деградировать управляемо (очередь, отказ части запросов), а не падать целиком.

Инструменты: wrk и ab для быстрой проверки эндпоинта, k6 и Locust для сценариев, JMeter для сложных корпоративных схем. Отдельно: нагрузочный тест снаружи по чужой инфраструктуре без согласования неотличим от DDoS — предупреждайте провайдера.

Негативное тестирование

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

Что подают на вход: пустое значение и очень длинную строку; буквы там, где ждут число; отрицательное количество товара; битый JSON и дату 31 февраля; чужой идентификатор — проверить, что доступ не выдадут; строки со спецсимволами и кавычками — SQL-инъекции и XSS живут ровно здесь.

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

Уровни тестирования

По возрастанию охвата: unit — функция в изоляции (быстрые, их тысячи, гоняются на каждом коммите); интеграционные — модуль вместе с БД, очередью и внешним API; E2E — сценарий целиком глазами пользователя (самые медленные и хрупкие, их держат мало); регрессионные — проверка, что починенное не сломалось снова, каждый найденный баг превращается в такой тест; smoke — минимальный набор после деплоя: сервис вообще жив?

Всё это имеет смысл только автоматически в CI/CD: тесты, которые запускают руками перед релизом, не запускают никогда.

Метрики качества ML-моделей

Для моделей роль бенчмарка играют свои метрики: perplexity для языковых моделей, WER для распознавания речи, accuracy и F1 для классификации. Для сервинга смотрят tokens per second и TTFT — причём обязательно при реальном batching: замер на одном запросе показывает совсем другую картину, чем production под нагрузкой.

Связанные термины

• throughput — пропускная способность, метрикой которой является RPS
• latency — задержка, вторая половина любого замера
• FLOPS / TFLOPS — синтетическая метрика производительности GPU
• SLA и отказоустойчивость — куда попадают целевые перцентили
• CI/CD — где тесты запускаются автоматически
• tokens per second — бенчмарк LLM-сервинга