Performance Test Automation

1 The Hook — Why This Matters

In 2023, a NZ travel booking site launched a "black Friday" sale campaign. Their checkout API, which handled 50 requests per second in normal operations, spiked to 800 RPS. Response times went from 200ms to 12 seconds. The database connection pool exhausted. Customers abandoned carts. The company lost an estimated $2.3M in revenue in four hours. They had load-tested the previous year, but no one had automated the tests in CI. The performance regression had crept in over six months of "small" releases.

Performance that isn't continuously tested is performance that will eventually fail. One-off load tests are theatre. Automated performance gates in CI are engineering.

2 The Rule — The One-Sentence Version

A performance test without a threshold is just a benchmark. A benchmark without a baseline comparison is just a number. Numbers don't protect production.

3 The Analogy — Think Of It Like...

4 Watch Me Do It — Step by Step

Here is how to build a production-grade performance automation suite with k6.

1. Write a smoke test (fast CI gate)

   import http from "k6/http";
   import { check, sleep } from "k6";
   
   export const options = {
     vus: 5, duration: "1m",
     thresholds: {
       http_req_duration: ["p(95)<500"],
       http_req_failed: ["rate<0.01"],
     },
   };
   
   export default function () {
     const res = http.get("https://api.example.com/health");
     check(res, {
       "status is 200": (r) => r.status === 200,
       "response time < 200ms": (r) => r.timings.duration < 200,
     });
     sleep(1);
   }

2. Write a load test with stages

   export const options = {
     scenarios: {
       ramp_up: {
         executor: "ramping-vus",
         stages: [
           { duration: "2m", target: 50 },
           { duration: "5m", target: 50 },
           { duration: "2m", target: 100 },
           { duration: "5m", target: 100 },
           { duration: "2m", target: 0 },
         ],
       },
     },
     thresholds: {
       http_req_duration: ["p(95)<500", "p(99)<1000"],
       http_req_failed: ["rate<0.01"],
     },
   };

3. Integrate into CI with baseline comparison

   # .github/workflows/performance.yml
   name: Performance Regression
   on:
     push: { branches: [main] }
     schedule:
       - cron: "0 6 * * 1-5"
   
   jobs:
     perf-test:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: grafana/setup-k6-action@v1
         - run: k6 run --env BASE_URL=${{ secrets.STAGING_URL }} tests/performance/load.js
         - run: python scripts/compare_perf_baseline.py results.json

Second example: Endurance (soak) test for memory leaks

export const options = {
  scenarios: {
    soak: {
      executor: "constant-vus",
      vus: 50,
      duration: "4h",  // Run for 4 hours to detect memory leaks
      env: { SOAK_TEST: "true" }
    },
  },
  thresholds: {
    "vus": ["value<=50"],  // Verify VUs don't crash
    "http_req_failed": ["rate<0.01"],
    "http_req_duration": ["p(99)<5000"],  // Watch for degradation over time
  },
};

// Script logs memory metrics every 15 min
let lastMemory = 0;
export default function () {
  // Simulate realistic user flow
  http.get("https://api.example.com/user/profile");
  http.post("https://api.example.com/cart/add", payload);

  // Every 50 requests, check if memory is degrading
  if (__VU % 50 === 0) {
    let currentMemory = metrics.systemMemory.value;
    if (currentMemory > lastMemory * 1.1) {
      console.warn(`Memory spike detected: ${lastMemory}MB -> ${currentMemory}MB`);
    }
    lastMemory = currentMemory;
  }
}

5 When to Use It / When NOT to Use It

6 Common Mistakes — Don't Do This

7 Now You Try — Interview Warm-Up

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to practice.

9 Interview Prep — Senior Q&A

Performance engineers ask about SLO design and regression detection. Questions from NZ fintech teams.