Executors, scenarios и управление нагрузкой

Почему всегда через scenarios

• K6 принимает executors только внутри options.scenarios.
• Top-level vus/duration/stages — shortcuts для простых случаев, но не для кастомных executors.
• Требование курса: все примеры c кастомными executors — через scenarios, чтобы они запускались без сюрпризов.

Готовые шаблоны

// scenarios.js
import http from "k6/http";
import { sleep } from "k6";
 
export const options = {
  scenarios: {
    smoke: {
      executor: "shared-iterations",
      iterations: 50,
      vus: 5,
      maxDuration: "3m",
      tags: { flow: "smoke" },
    },
    load: {
      executor: "ramping-vus",
      startVUs: 10,
      stages: [
        { duration: "5m", target: 100 }, // ramp-up
        { duration: "20m", target: 100 }, // плато
        { duration: "5m", target: 0 }, // ramp-down
      ],
      gracefulRampDown: "2m",
      tags: { flow: "checkout" },
    },
    steady_rps: {
      executor: "constant-arrival-rate",
      rate: 300, // tps/rps
      timeUnit: "1s",
      duration: "15m",
      preAllocatedVUs: 50,
      maxVUs: 300,
      tags: { flow: "browse" },
    },
    external: {
      executor: "externally-controlled",
      vus: 0,
      maxVUs: 500,
      duration: "30m",
      tags: { flow: "ops" },
    },
  },
};
 
export default function () {
  http.get(`${__ENV.BASE_URL}/api/ping`);
  sleep(1);
}

Как выбирать:

• shared-iterations — быстро прогнать N действий (smoke).
• per-vu-iterations — фиксированное число итераций на VU, удобно для сценариев с подготовкой state.
• ramping-vus — реалистичный рост/спад пользователей.
• constant-arrival-rate и ramping-arrival-rate — держим RPS независимо от скорости ответов (нужен запас VU).
• externally-controlled — управление нагрузкой из Grafana/k6 Cloud/REST API.

Когда что выбирать

• ramping-vus: важен профиль живых пользователей и think time. Подходит для веб-флоу и UX.
• constant/ramping-arrival-rate: фиксированный RPS/TPM, имитация API-трафика или очередей. Требует запаса maxVUs.
• shared/per-vu-iterations: быстрые smoke/регрессии на N действий, минимальный overhead.
• externally-controlled: ручное управление нагрузкой из Grafana/k6 Cloud или REST API.

Правило: если цель измеряет «пользовательский опыт» — берите ramping-vus; если цель — «держать X rps» — берите constant/ramping-arrival-rate.

Визуализация паттернов нагрузки

Как k6 исполняет ваш код (важно для лимитов)

• Один VU = горутина, нет общего event loop как в Node. sleep отдает управление планировщику k6, но не блокирует другие VU.
• http.batch() запускает запросы параллельно внутри VU, но тайминги учитываются в метриках как отдельные запросы.
• Нет async/await: k6 синхронно исполняет JS, поэтому «параллельность» только через batch или несколько VU.
• Планируйте VU и rate исходя из payload/RTT: тяжелые ответы = больше времени в receive → нужно больше VU для удержания целевого RPS.

Troubleshooting: типичные проблемы с executors

scenarios: {
api_load: {
  executor: "constant-arrival-rate",
  rate: 300,
  timeUnit: "1s",
  duration: "10m",
  preAllocatedVUs: 200,
  maxVUs: 500, // Запас для пиков латентности
}
}

scenarios: {
load: {
  executor: "ramping-vus",
  startVUs: 0,
  stages: [
    { duration: "5m", target: 100 }
  ],
  gracefulRampDown: "30s", // Даём время завершить итерации
}
}

scenarios: {
load_test: {
  executor: "ramping-vus",
  stages: [
    { duration: "3m", target: 10 },   // Warmup: малая нагрузка
    { duration: "5m", target: 100 },  // Ramp-up
    { duration: "20m", target: 100 }, // Plateau (основной тест)
    { duration: "2m", target: 0 }     // Ramp-down
  ]
}
}

scenarios: {
warmup: {
  executor: "constant-arrival-rate",
  rate: 50,
  duration: "2m",
  preAllocatedVUs: 20,
  maxVUs: 50,
  startTime: "0s",
},
main_load: {
  executor: "constant-arrival-rate",
  rate: 300,
  duration: "15m",
  preAllocatedVUs: 150,
  maxVUs: 400,
  startTime: "2m", // Начнется после warmup
}
}

✅ Чек-лист завершения урока

После этого урока вы должны уметь:

Понимание executors:

• Знаете, когда использовать ramping-vus vs constant-arrival-rate
• Понимаете разницу между VU-based (vus) и RPS-based (arrival-rate) executors
• Знаете, что такое preAllocatedVUs и maxVUs для arrival-rate
• Понимаете, зачем нужен warmup и как его добавить

Практика с scenarios:

• Написали тест с ramping-vus: warmup → ramp-up → plateau → ramp-down
• Написали тест с constant-arrival-rate: rate, preAllocatedVUs, maxVUs
• Добавили tags для разделения потоков: { flow: 'checkout' }
• Добавили gracefulRampDown для плавного завершения

Troubleshooting:

• Знаете, что значит dropped_iterations и почему это критично
• Умеете проверить CPU/RAM генератора во время теста
• Понимаете, когда увеличивать maxVUs для arrival-rate
• Знаете, как добавить несколько scenarios в один тест

Анализ поведения:

• Запустили ramping-vus и наблюдали, как RPS зависит от latency
• Запустили constant-arrival-rate и убедились, что RPS стабилен
• Сравнили результаты: какой executor подходит для вашего сценария?

Практическое задание:

• Создали load-test.js с правильным executor для вашего user journey
• Проверили, что dropped_iterations = 0
• Экспортировали baseline: --summary-export baseline-load.json