Performance Testing Learning Path: Start Here
In short: you learn performance testing in 6 milestones on a small practice app that runs on your own machine and has three deliberate problems — a CPU-heavy endpoint, a tiny connection pool and a memory leak. Each milestone finds, proves or fixes one of them, with an answer key.
Read this page once to see the plan. Then, for each milestone, follow the same four steps: learn → test → check → commit. Come back here whenever you're unsure what to do next.
Before you start
- Node.js 20+ and k6 installed.
- The practice lab saved as
app/server.jsand running:node --expose-gc app/server.js. - Basic JavaScript (functions, objects) — k6 scripts are JavaScript.
- Helpful: the API testing cheat sheet, sections 1–8.
The pages in this learning path
| Page | What it's for | When to open it |
|---|---|---|
| This roadmap | The plan and self-checks | At the start of each milestone |
| Performance testing cheat sheet | Learn each idea, with real results from the lab | The "learn" step |
| Milestones & Mini-Projects | Tasks, expected results, answer keys | The "test" and "check" steps |
| Quick Reference | Formulas, k6 options, executors, bottleneck signs | Any time |
| Best Practices | Habits that make results believable | After Milestone 3, then before every report |
| Performance testing guide | The whole service | For the deeper "why" |
The milestones
| Milestone | You learn | You work on | Rough time |
|---|---|---|---|
| 1 | Metrics, percentiles, checks, thresholds | Smoke test + reading results | 1 week |
| 2 | Workload models, executors, tags, test data | Load test at expected peak | 1 week |
| 3 | Little's Law, stress testing, bottlenecks | Find the orders capacity — and raise it | 1–2 weeks |
| 4 | Spike testing, recovery | A sale-start burst | 1 week |
| 5 | Soak testing, resource metrics | Find and fix the memory leak | 1 week |
| 6 | CI gates, baselines, reporting | A deploy gate and a full report | 1–2 weeks |
Times assume about 5 hours a week.
For each milestone:
- Learn — read the cheat-sheet sections below and run their examples.
- Test — do the tasks in Milestones & Mini-Projects.
- Check — compare with the expected results, then open the answer key.
- Commit — scripts, results (
summary.json) and notes:
perf-portfolio/
├── app/server.js
├── tests/smoke.js load.js stress.js spike.js soak.js ci-gate.js
├── data/search-terms.json
├── results/<date>-<test>.json
└── reports/performance-report.md
Milestone 1: Metrics & first test
Learn: What performance testing is · Test types · Key metrics · Percentiles · Your first k6 test · Reading the summary · Checks vs thresholds · Virtual users & think time
Work on: Smoke test
Check yourself:
- Why report p95 instead of the average?
- What's the difference between a check and a threshold?
- What does k6's exit code 99 mean?
Milestone 2: Load test
Learn: Workload model · Scenarios & executors · Load test · Test data · Tags & per-endpoint limits
Work on: Load test at peak
Check yourself:
- Why use an arrival-rate executor for web traffic?
- Why vary test data?
- What does
dropped_iterationstell you?
Milestone 3: Stress & capacity
Learn: Little's Law · Stress test · Finding the bottleneck · Custom metrics · Quick Reference: Formulas, Bottleneck signs
Work on: Find the orders capacity
Then read: Best Practices, sections 1–6.
Check yourself:
- Predict the maximum throughput of a pool of 8 connections held 40 ms each.
- Which lab metric proved the pool was the bottleneck?
- Why use
abortOnFailin stress tests?
Milestone 4: Spike & recovery
Learn: Spike test · Quick Reference: Thresholds
Work on: A sale-start burst
Check yourself:
- Why split a spike test into before / during / after scenarios?
- "No errors" — does that mean the spike went well?
Milestone 5: Soak & leaks
Learn: Soak test · Realistic environments · Quick Reference: Data and lifecycle
Work on: Find and fix the memory leak
Check yourself:
- Why can a soak test pass every response-time threshold and still fail?
- Why does the lab force garbage collection before reporting memory?
Milestone 6: CI gate & report
Learn: CI gates · Reporting · Front-end performance · Quick Reference: Report outline
Work on: A deploy gate and a report
Then read: Best Practices, sections 7–11.
Check yourself:
- Why can a loose threshold miss a 3× slowdown — and what catches it instead?
- What goes in the first line of a performance report?
When you get stuck
| Problem | What to do |
|---|---|
connection refused | The lab isn't running — start it; check nothing else uses port 3333 |
| Results change a lot between runs | Close other heavy apps; run twice; compare medians too |
dropped_iterations on arrival-rate tests | Raise maxVUs — or the system is so slow that all VUs are busy (that's a finding) |
| Memory numbers jump around | Start the lab with --expose-gc so /metrics collects garbage first |
| Your laptop's fan screams | Your generator and the lab share a machine; keep rates modest — the shapes still teach |
What's next
- Observe systems properly: Observability guide.
- Go deeper on system resources: System performance guide.
- Enterprise tool: JMeter guide.
Good books to read alongside: Systems Performance (Brendan Gregg) for the USE method and resource analysis, and the free k6 documentation for every option.