API Performance Testing: Load, Stress and Spike Tests with k6

An API that answers in 120 ms for one tester can take 9 seconds when 20,000 shoppers hit it at midnight on sale day, or simply fall over. Performance testing finds those limits before your users do. In this lesson you’ll learn the metrics that matter (and why averages lie), the main types of performance tests, how to write a load test in k6, how to add quick latency checks to your Playwright suite, and how to read the results like an engineer.

The Metrics That Matter

Types of Performance Tests

Before You Load Test: Ground Rules

1. Define goals: “p95 < 800 ms, errors < 1% at 300 RPS for 30 minutes”.
2. Model real traffic: which endpoints, in what mix (e.g. 70% browse, 20% search, 10% checkout), think time between calls.
3. Production-like environment: similar data volumes, configuration and infrastructure.
4. Test data: enough unique users, products and tokens so caches don’t make results unrealistically good.
5. Monitoring: watch server metrics (APM, dashboards) during the test, not just client-side numbers.

Your First k6 Load Test

k6 is a free, open-source load testing tool where scripts are written in JavaScript. Install it from k6.io (Windows, macOS, Linux or Docker), then save this as users-load.js:

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

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1';

export const options = {
  vus: 3,                 // 3 virtual users - deliberately tiny for the shared practice API
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<1500'],   // 95% of requests faster than 1.5 s
    http_req_failed: ['rate<0.01'],      // less than 1% errors
    checks: ['rate>0.99'],
  },
};

export default function () {
  const res = http.get(`${BASE}/users?per_page=5`);
  check(res, {
    'status is 200': (r) => r.status === 200,
    'has 5 users': (r) => r.json('data').length === 5,
  });
  sleep(1);               // think time: a real user pauses between actions
}

k6 run users-load.js

k6 prints a summary including http_req_duration (avg, min, med, max, p90, p95), http_reqs (throughput), http_req_failed and whether each threshold passed. A failed threshold gives a non-zero exit code, so k6 can gate a CI pipeline.

Ramping load with stages (load, stress, spike)

// For YOUR performance environment, not the practice API
export const options = {
  stages: [
    { duration: '2m', target: 100 },    // ramp up to 100 users
    { duration: '10m', target: 100 },   // hold: load test
    { duration: '2m', target: 400 },    // push beyond: stress
    { duration: '30s', target: 1500 },  // sudden spike
    { duration: '2m', target: 0 },      // ramp down: does it recover?
  ],
  thresholds: { http_req_duration: ['p(95)<800'], http_req_failed: ['rate<0.01'] },
};

A realistic user journey

import http from 'k6/http';
import { check, group, sleep } from 'k6';

export default function () {
  let token;
  group('login', () => {
    const res = http.post(`${__ENV.BASE}/auth/login`,
      JSON.stringify({ username: __ENV.USER, password: __ENV.PASS }),
      { headers: { 'Content-Type': 'application/json' } });
    check(res, { 'login 200': (r) => r.status === 200 });
    token = res.json('access_token');
  });
  sleep(2);
  group('browse and order', () => {
    const auth = { headers: { Authorization: `Bearer ${token}` } };
    check(http.get(`${__ENV.BASE}/products?category=books`, auth), { 'browse 200': (r) => r.status === 200 });
    sleep(3);
    // ... add to cart, checkout
  });
}

Run with k6 run -e BASE=https://perf.example.com/api -e USER=perf_user_1 -e PASS=... journey.js; secrets come from the environment, not the script.

Reading Results: A Worked Example

The pattern to recognise: when throughput stops growing but response time keeps rising, you’ve found a bottleneck (CPU, DB connection pool, a slow query, a lock, a downstream API). Pair the timing with server metrics to locate it.

Rate Limits, Timeouts and Retries

Performance testing also covers how the API protects itself and how clients behave:

• Rate limits: the practice API’s /rate-limit endpoint allows 5 calls per minute, then returns 429 with Retry-After and X-RateLimit-* headers.
• Slow dependencies: /delay/{seconds} waits up to 10 seconds, ideal for testing client timeouts.
• Client behaviour: does the app back off on 429/503, or hammer the server harder (a “retry storm”)?

curl -i \
  "https://sqatools.in/wp-json/sqa-api/v1/delay/2"

Quick Latency Checks Inside Your Playwright Suite

You don’t need a load tool to catch obvious regressions. A small sequential sample in your functional suite flags an endpoint that suddenly got slow:

import { test, expect } from '@playwright/test';

const BASE = 'https://sqatools.in/wp-json/sqa-api/v1/';

function percentile(values: number[], p: number) {
  const sorted = [...values].sort((a, b) => a - b);
  return sorted[Math.min(sorted.length - 1, Math.ceil((p / 100) * sorted.length) - 1)];
}

test('GET users: p95 under 2 s over 15 calls', async ({ request }) => {
  const timings: number[] = [];
  for (let i = 0; i < 15; i++) {
    const start = performance.now();
    const res = await request.get(`${BASE}users?per_page=5`);
    timings.push(performance.now() - start);
    expect(res.status()).toBe(200);
  }
  const p95 = percentile(timings, 95);
  test.info().annotations.push({ type: 'p95 ms', description: p95.toFixed(0) });
  expect(p95).toBeLessThan(2_000);
});

test('client gives up on a slow endpoint', async ({ request }) => {
  const start = Date.now();
  await expect(request.get(`${BASE}delay/5`, { timeout: 2_000 })).rejects.toThrow(/Timeout/);
  expect(Date.now() - start).toBeLessThan(3_500);
});

test('rate limit answers 429 with Retry-After', async ({ request }) => {
  let last;
  for (let i = 0; i < 6; i++) last = await request.get(`${BASE}rate-limit`);
  expect(last!.status()).toBe(429);
  expect(Number(last!.headers()['retry-after'])).toBeGreaterThan(0);
});

These are not load tests (one user, sequential calls); they’re cheap guards against performance regressions that run on every build. The rate-limit test shares a per-IP counter, so don’t run it in parallel with itself.

Tools Compared

Common Performance Testing Mistakes

• Reporting averages only.
• Testing from a laptop on office Wi-Fi: the load generator becomes the bottleneck.
• Using the same user and same product id for every request, so caches hide real costs.
• No think time: 100 VUs without pauses behave like thousands of real users.
• Ignoring errors: a fast 500 isn’t a fast success. Check responses in the script.
• One run and done: compare with a baseline on every release.

Interview Questions: API Performance Testing