Grafana k6 Performance Testing Interview Questions for Senior Level (2026)

Short answer: in a closed model a fixed number of virtual users loop, so when the system slows down, fewer requests are sent (constant-vus, ramping-vus). In an open model new iterations start at a set rate regardless of response time (constant-arrival-rate, ramping-arrival-rate). Real public traffic usually behaves like the open model.

export const options = {
  scenarios: {
    checkout: {
      executor: 'constant-arrival-rate',
      rate: 50,              // 50 iterations started...
      timeUnit: '1s',        // ...every second
      duration: '10m',
      preAllocatedVUs: 100,
      maxVUs: 400,
    },
  },
};

If k6 warns that it ran out of VUs, the target rate was not reached - raise maxVUs or check whether the system has already saturated.

Short answer: when a load tool waits for slow responses before sending the next request, it sends fewer requests exactly when the system is struggling, so the slow period is under-recorded and latency looks better than users experience. Arrival-rate executors keep starting iterations on schedule, which avoids this bias.

• Smoke: minimal load - does the script and system work at all?
• Average load: expected normal traffic - do we meet our targets?
• Stress: above normal - how does it behave and degrade?
• Spike: a sudden surge - does it survive and recover?
• Soak: normal load for hours - memory leaks, connection exhaustion?
• Breakpoint: keep increasing until it fails - where is the limit?

Always run a smoke test before a big run, so a broken script does not waste an expensive test window.

Short answer: use SharedArray, which loads the file once and shares it read-only between VUs instead of copying it into each one.

import { SharedArray } from 'k6/data';
import exec from 'k6/execution';

const users = new SharedArray('users', () => JSON.parse(open('./users.json')));

export default function () {
  const user = users[exec.scenario.iterationInTest % users.length];
  // log in as user.email ...
}

Using a different user per iteration avoids results skewed by one account's cache or rate limits.

Short answer: a check verifies a single response and records pass/fail, but never fails the test on its own. A threshold is a pass/fail rule on a metric for the whole run; if it is crossed, k6 exits with a non-zero code, which fails the CI job.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500', 'p(99)<1500'],
    checks: [{ threshold: 'rate>0.99', abortOnFail: true, delayAbortEval: '1m' }],
  },
};

export default function () {
  const res = http.get('https://test.k6.io');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

Take threshold values from agreed service targets, not from numbers that "look reasonable".

Short answer: averages hide the slow tail. If most requests take 100 ms and a few take 5 seconds, the average still looks fine while some users wait 5 seconds. p95 and p99 show what the slowest 5% and 1% experience. Report them per endpoint, because a fast health check can mask a slow checkout in a combined number.

Short answer: monitor the machine running k6 too. If its CPU is near its limit or network bandwidth is maxed, the results describe the generator, not the system under test. Signs include rising http_req_blocked or dropped-iteration warnings.

Fixes: reduce per-iteration work (avoid heavy JavaScript processing), discard response bodies you do not need (discardResponseBodies), or spread the load across several generators or a cloud service.

Short answer: link the load level where latency or errors start rising to what the server was doing at that moment.

1. Note the rate at which p95 or error rate crossed the target.
2. Line that time up with server metrics (CPU, memory, DB connections, queue depth) and traces in your monitoring tool.
3. Name the limiting resource, and re-test after a change to confirm it moved.
4. Report the measured capacity, the test conditions (data size, environment size) and how they differ from production.