Нагрузочное тестирование с k6

01Виды тестов производительности

Термин «нагрузочный тест» используют вольно, но каждый вид отвечает на свой вопрос. Smoke-тест даёт крошечную нагрузку, чтобы проверить, что скрипт и система работают. Тест средней нагрузки имитирует обычный трафик и подтверждает, что вы укладываетесь в целевые показатели. Стресс-тест выходит за пределы нормы, чтобы увидеть, как деградирует система. Spike-тест резко подскакивает, как после push-уведомления. Soak-тест (тест на выносливость) держит обычную нагрузку часами, чтобы найти утечки памяти и медленное истощение ресурсов. Breakpoint-тест наращивает нагрузку, пока что-нибудь не сломается, чтобы найти реальную ёмкость. Начните со smoke и средней нагрузки; остальные добавляйте, когда узнаете свою базовую линию.

• Пропускная способность: число запросов или итераций в секунду, которые выполняет система.
• Перцентили задержки: p95 означает, что 95% запросов были быстрее этого значения.
• Доля ошибок: процент неудачных запросов, часто первое, что ломается.

02Ваш первый скрипт k6

Скрипт k6 — это ES-модуль. Экспорт options описывает нагрузку и правила прохождения; функция по умолчанию — то, что каждый виртуальный пользователь (VU) выполняет в цикле. VU — это симулированный пользователь, который выполняет вашу функцию параллельно с остальными. check() проверяет ответы, не останавливая тест; thresholds превращают метрики в результат «прошёл/не прошёл», и k6 завершается с ненулевым кодом, если порог не пройден, — именно это ломает сборку в CI. sleep() добавляет время на размышление, чтобы VU вёл себя как реальный человек, а не как плотный цикл. k6 запускает файлы TypeScript напрямую, так что в больших наборах тестов можно использовать типы.

1import http from "k6/http";
2import { check, sleep } from "k6";
3 
4export const options = {
5  vus: 20,
6  duration: "2m",
7  thresholds: {
8    http_req_failed: ["rate<0.01"],                  // under 1% errors
9    http_req_duration: ["p(95)<400", "p(99)<1000"],  // ms
10  },
11};
12 
13export default function () {
14  const res = http.get("https://staging.example.com/api/products?page=1");
15  check(res, { "status is 200": (r) => r.status === 200 });
16  sleep(1);
17}

03Сценарии и executors: открытая и закрытая модели

Сценарии позволяют точно формировать нагрузку и запускать несколько паттернов одновременно. Executors определяют, как именно. Executors закрытой модели (constant-vus, ramping-vus) держат занятым заданное число VU; если система замедляется, каждый VU делает меньше запросов, и это скрывает проблему. Executors открытой модели (constant-arrival-rate, ramping-arrival-rate) запускают новые итерации с фиксированной частотой независимо от времени ответа, что соответствует реальному интернет-трафику: пользователи продолжают приходить, даже когда сайт тормозит. Для тестов ёмкости API предпочитайте arrival-rate executors и давайте им достаточно preAllocatedVUs и maxVUs, чтобы выдерживать заданную частоту.

1export const options = {
2  scenarios: {
3    browse: {
4      executor: "ramping-arrival-rate",
5      startRate: 10, timeUnit: "1s",
6      preAllocatedVUs: 50, maxVUs: 300,
7      stages: [
8        { target: 100, duration: "3m" }, // ramp to 100 requests/s
9        { target: 100, duration: "10m" }, // hold
10        { target: 0, duration: "2m" },   // ramp down
11      ],
12    },
13  },
14  thresholds: { "http_req_duration{scenario:browse}": ["p(95)<500"] },
15};

04Реалистичные пользовательские сценарии

Реальные пользователи логинятся, просматривают, ищут и оформляют заказ, делая паузы между шагами. Моделируйте основные сценарии в реальных пропорциях из аналитики (например, 80% просмотр, 15% поиск, 5% checkout). Используйте group() для именования шагов, теги для разбивки метрик и SharedArray, чтобы загрузить тестовые данные один раз и разделить их между VU без копирования памяти. Там, где есть запись, генерируйте уникальные данные для каждого VU и итерации, чтобы не попадать в одну и ту же строку и не создавать искусственную конкуренцию за блокировки. Подготовку (создание тестового аккаунта, получение токена) делайте в setup(), который выполняется один раз, и передавайте результат в VU.

1import http from "k6/http";
2import { group, check } from "k6";
3import { SharedArray } from "k6/data";
4 
5const products = new SharedArray("products", () => JSON.parse(open("./products.json")));
6const BASE = __ENV.BASE_URL || "https://staging.example.com";
7 
8export function setup() {
9  const res = http.post(BASE + "/api/login", JSON.stringify({ email: "[email protected]", password: __ENV.TEST_PASSWORD }),
10    { headers: { "Content-Type": "application/json" } });
11  return { token: res.json("token") };
12}
13 
14export default function (data) {
15  const params = { headers: { Authorization: "Bearer " + data.token } };
16  group("product page", () => {
17    const p = products[Math.floor(Math.random() * products.length)];
18    check(http.get(BASE + "/api/products/" + p.slug, params), { "200": (r) => r.status === 200 });
19  });
20}

05Запуск, чтение результатов и CI

Запускайте k6 run script.js локально или в контейнере. В конце k6 выводит сводку: частоту запросов, перцентили задержки, долю ошибок, объём переданных данных и то, пройден ли каждый порог. Смотрите на p95 и p99, а не на средние значения, потому что среднее скрывает медленный хвост, который замечают пользователи. Для трендов и корреляции с серверными метриками стримьте результаты в Prometheus (remote write) или Grafana Cloud k6 и смотрите их рядом с дашбордами CPU, базы данных и очередей. В CI запускайте короткий smoke-тест или тест средней нагрузки на каждый релиз против staging, а более длинные стресс- и soak-тесты держите по расписанию. Никогда не нагружайте продакшен или сторонний API без явного разрешения и плана.

1# Local run with an environment variable
2k6 run -e BASE_URL=https://staging.example.com script.js
3 
4# Docker, no local install
5docker run --rm -i grafana/k6 run - <script.js
6 
7# Stream metrics to Prometheus remote write
8K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
9  k6 run -o experimental-prometheus-rw script.js

06Закон Литтла и расчёт размера теста

Закон Литтла связывает три числа: параллелизм = пропускная способность × время в системе. Если нужно 200 запросов в секунду, а запрос занимает 0,25 секунды, в системе одновременно находится около 50 запросов. Для arrival-rate тестов k6 нужное число VU ≈ частота × длительность итерации (включая sleep), поэтому сценарий длиной 2 секунды при 50 итерациях в секунду требует около 100 VU; задайте maxVUs с запасом. Тот же закон объясняет пределы сервера: пул PHP-FPM из 40 воркеров при запросах по 200 ms упирается примерно в 200 запросов в секунду, и всё, что выше, встаёт в очередь. Если задержка резко растёт, а пропускная способность выходит на плато, вы где-то упёрлись в лимит параллелизма: пул воркеров, соединения с базой данных или блокировку.

07Поиск узкого места во время теста

k6 говорит вам, что что-то медленное; серверные метрики говорят, почему. Следите по порядку: CPU приложения и насыщение воркеров, CPU базы данных, slow query log и соединения, cache hit ratio, глубина очередей и задержка внешних API. Применяйте метод USE (utilisation, saturation, errors) к каждому ресурсу. Тегируйте запросы в k6 по имени эндпоинта, чтобы URL с ID группировались (используйте тег name), и сопоставляйте самые медленные эндпоинты с трейсами в APM. Исправляйте по одному узкому месту за раз и перезапускайте тот же тест; следующее узкое место обычно проявляется сразу. Ведите журнал результатов с коммитом, конфигурацией и ключевыми цифрами для каждого прогона, чтобы сравнивать честно.

1// Group dynamic URLs under one metric name
2http.get(BASE + "/api/products/" + id, { tags: { name: "GET /api/products/:id" } });
3 
4// Custom metric for a business step
5import { Trend } from "k6/metrics";
6const checkoutTime = new Trend("checkout_duration", true);
7checkoutTime.add(res.timings.duration);

08Coordinated omission и пределы генератора

Coordinated omission возникает, когда генератор нагрузки ждёт медленных ответов перед отправкой следующего запроса, поэтому отправляет меньше запросов именно тогда, когда системе тяжело, и измеренная задержка выглядит лучше реальной. Executors закрытой модели страдают от этого по своей природе. Arrival-rate executors избегают большей части проблемы, запуская итерации по расписанию, но если у них заканчиваются VU, k6 сообщает dropped_iterations, и это нужно считать сигналом провала. Также следите за генератором: если его CPU выше примерно 80%, тайминги становятся ненадёжными. Для больших тестов распределяйте нагрузку на несколько машин с помощью k6 Operator в Kubernetes или Grafana Cloud k6 и генерируйте нагрузку из того же региона, где находятся пользователи.

09Тестирование за пределами HTTP: WebSockets, gRPC и расширения

В k6 есть встроенные модули для HTTP/1.1 и HTTP/2, WebSockets, gRPC и браузера, а расширения (собираются через xk6, а в новых версиях официальные подключаются автоматически) добавляют протоколы вроде Kafka, SQL или Redis. Это позволяет тестировать части системы, до которых HTTP не дотягивается: WebSocket-чат с тысячами соединений, gRPC service mesh или пропускную способность консьюмера очереди. Относитесь к этим тестам так же, как к HTTP: реалистичная частота сообщений, пороги на задержку и ошибки, мониторинг на стороне сервера. Для событийных систем измеряйте сквозное время от публикации до эффекта, а не только вызов публикации.