📊 Performance Testing Tools

Why Performance Testing?

Functional testing answers "does it work?" Performance testing answers a harder question: "does it still work when everyone shows up at once?" A checkout endpoint that responds in 40 ms with one user might crawl to 4 seconds — or fall over entirely — under the traffic of a flash sale. You want to discover that on a Tuesday afternoon in a test environment, not at 9 PM on Black Friday.

The numbers make the case. Public engineering write-ups have long reported the same pattern: every extra 100 ms of latency measurably shaves conversions, and users abandon pages that take more than a few seconds to respond. Slow isn't a cosmetic problem — it's a revenue problem, a retention problem, and increasingly an SEO problem.

The Four Load-Test Types

"Run a load test" is like "cook dinner" — it hides several very different activities. The shape of the traffic you generate defines what you're actually testing. There are four classic patterns, and they answer four different questions.

The Metrics That Matter

A load test spits out a wall of numbers. Four of them carry almost all the signal.

Throughput (requests per second)

Throughput, usually reported as RPS (requests per second), is how much work the system completes per unit of time. It's the "how many customers can we serve" number. Higher is better — up to the point where the server saturates and throughput flattens no matter how much load you add.

Latency — and why the average lies

Latency is how long a single request takes. The trap is reporting it as an average. Imagine 99 requests at 50 ms and one request at 5000 ms: the average is a comfortable-sounding ~100 ms, yet one in a hundred users waited five full seconds. Averages hide the users who suffer.

The fix is percentiles. The p95 latency is the value that 95% of requests came in under; p99 is the same for 99%. These describe the tail — the slow requests real users complain about.

Average latency  ...........  102 ms   ← looks great
p50 (median) ...............   48 ms
p95 ........................  240 ms
p99 ........................ 1900 ms   ← 1 in 100 users waited ~2 s

Error rate

The percentage of requests that failed — timeouts, 5xx responses, dropped connections. Under load, an app often stays fast right up until it starts failing. A rising error rate is frequently the first sign you've hit capacity. Anything above ~1% usually deserves immediate attention.

Concurrency

Concurrency is how many requests are in flight at the same moment — the pressure you're applying. Load tools express it two ways: a fixed number of virtual users (VUs) each looping, or an arrival rate (new users per second). The distinction matters: arrival-rate models are closer to how real traffic behaves, because real users don't wait politely for the previous one to finish.

The Tool Landscape

Dozens of tools generate load. For a JavaScript full-stack developer, three matter most, plus a handful of lightweight helpers.

Grafana k6 — the modern default

k6 is a load-testing tool you script in JavaScript but that runs on a fast Go engine. That combination — familiar language, high performance, tiny resource footprint — has made it the de-facto modern standard. Tests are code, so they live in your repo, review in pull requests, and run in CI.

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

// Options define the traffic shape AND the pass/fail thresholds (the SLA).
export const options = {
  stages: [
    { duration: '30s', target: 20 },  // ramp up to 20 virtual users
    { duration: '1m',  target: 20 },  // hold at 20 for a minute
    { duration: '30s', target: 0 },   // ramp back down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'], // 95% of requests must finish under 500 ms
    http_req_failed:   ['rate<0.01'], // error rate must stay under 1%
  },
};

export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status is 200':     (r) => r.status === 200,
    'body is not empty':  (r) => r.body.length > 0,
  });
  sleep(1); // "think time" — pause like a real user before the next request
}

Why it matters: those thresholds turn a load test into a gate. If p95 exceeds 500 ms or errors exceed 1%, k6 exits non-zero and your CI build fails — exactly the SLA-as-code behavior you want.

Artillery — YAML scenarios, Node-native

Artillery is a Node.js load tester where you describe traffic in readable YAML and drop into JavaScript only when you need custom logic. It excels at multi-step user journeys and integrates naturally with a Node stack. We devote the next lesson entirely to it.

config:
  target: "https://api.example.com"
  phases:
    - duration: 60
      arrivalRate: 5
      rampTo: 50
      name: "Warm up"
scenarios:
  - name: "Browse products"
    flow:
      - get:
          url: "/products"
          expect:
            - statusCode: 200
      - think: 3
      - get:
          url: "/products/{{ $randomNumber(1, 100) }}"

Apache JMeter — the veteran

JMeter is a mature, Java-based tool with a GUI and support for a huge range of protocols (HTTP, JDBC, JMS, FTP, and more). It's powerful and battle-tested, but heavier on resources and less friendly to a code-review workflow than k6 or Artillery. You'll meet it in enterprise shops and legacy pipelines.

Quick Benchmarking

Sometimes you don't need a scripted scenario — you just want a fast pulse-check on a single endpoint. Two tiny command-line tools cover that.

Apache Bench (ab) and hey

ab ships with Apache and has measured HTTP servers for decades. hey is a modern Go rewrite with HTTP/2 support. Both fire a burst of requests and print throughput and latency percentiles in seconds.

# Apache Bench: 1000 requests, 50 at a time
ab -n 1000 -c 50 https://api.example.com/products

# hey: 2000 requests, 50 concurrent, with an auth header
hey -n 2000 -c 50 -H "Authorization: Bearer token123" https://api.example.com/users

A note on frontend performance

Load tools measure the server. To measure the browser experience — how fast a page paints and becomes interactive — use Lighthouse (built into Chrome DevTools and runnable in CI). It scores Core Web Vitals like Largest Contentful Paint and Cumulative Layout Shift. Different question, different tool, both worth automating.

Choosing the Right Tool

There's no universally "best" tool — only the best fit for a scenario. Walk through five questions and the choice usually makes itself.

Practice & Quiz

Best Practices & Pitfalls

✅ Do

• Report percentiles (p50/p95/p99), not just the average
• Watch the error rate — apps often fail before they slow down
• Model traffic with an arrival rate when you can — it mirrors real users
• Test against a production-like environment, with realistic data volumes
• Store load tests in your repo and run them in CI, like any other test

❌ Don't

• Judge performance by the average alone — it hides the tail
• Load-test production without permission and a plan (you can cause a real outage)
• Trust a 2-minute run to reveal leaks — that's what soak tests are for
• Reach for a heavyweight tool when ab or hey answers the question in seconds

Summary

📚 Additional Resources

• k6 — Official documentation
• Artillery — Official documentation
• Apache JMeter — User manual
• MDN — Web Performance guide

🚀 What's Next?

You know the landscape and the vocabulary. Next we go hands-on with one tool end to end — installing it, scripting realistic multi-step journeys, feeding it dynamic data, and reading its report: Load Testing with Artillery.