Performance fundamentals
You can't design a useful load test without understanding what you're measuring and why. Get the vocabulary and the test-type taxonomy right first.
Load, stress, soak, and spike tests
Running the wrong test type gives you results that answer the wrong question — one test plan does not cover all failure modes.
You'll learn to
- Define load, stress, soak, spike, and breakpoint tests
- Choose the right test type for a given risk scenario
- Design the ramp-up shape that matches your production traffic pattern
- Recognise what each test type can and can't reveal
Metrics: throughput, latency, and error rate
Average response time hides the outliers that break your SLA — p95 and p99 tell you what real users experience.
You'll learn to
- Distinguish throughput, response time, and latency
- Explain why averages mislead and use percentiles instead
- Define an SLA in measurable terms ("p95 < 500ms at 500 RPS")
- Identify the four common bottleneck types: CPU, memory, I/O, network
- Set a performance budget before writing a single test
k6 — the code-first load tool
k6 runs in CI, lives in Git, and is scripted in JavaScript. If you can write a function, you can write a load test.
Writing k6 scripts
k6 scripts are plain JavaScript — the sooner you treat them like code (DRY, reusable, reviewed) the fewer surprises at scale.
You'll learn to
- Write a k6 script from scratch: virtual users, stages, checks, and thresholds
- Parameterise scenarios with environment variables and CSV data files
- Use the k6 HTTP API to handle authentication, cookies, and headers
- Add checks and thresholds that turn test results into pass/fail verdicts
- Debug failing scripts with verbose logging and the k6 web dashboard
Running k6 in CI/CD
A load test you run manually once a quarter isn't a test suite — it's a fire drill. CI makes performance a regression gate on every PR.
You'll learn to
- Run k6 from a GitHub Actions workflow on push and PR
- Set threshold rules that fail the CI job on regression
- Store k6 summary output as build artefacts for trend analysis
- Keep execution fast enough for a PR check (smoke profile < 5 min)
- Manage target URLs and credentials with CI environment secrets
Streaming results to Grafana
CLI output disappears after the job finishes — a live dashboard shows trends across runs so you can spot the exact deploy that degraded throughput.
You'll learn to
- Stream k6 results to InfluxDB with the k6 built-in output
- Build a Grafana dashboard for RPS, p95, and error rate
- Compare runs side-by-side to identify regressions
- Set Grafana alerts that fire when a threshold is breached in production
JMeter for enterprise workloads
JMeter is the industry default in regulated and enterprise environments. Knowing it opens doors even if k6 is your daily driver.
Building JMeter test plans
JMeter's GUI does heavy lifting for correlation and parameterisation — skills that transfer directly to any load tool you pick up next.
You'll learn to
- Build a test plan with thread groups, HTTP samplers, and listeners
- Use CSV Data Set Config for data-driven virtual users
- Extract dynamic values with regex and JSON extractors
- Inject extracted values into subsequent requests (correlation)
- Run JMeter in non-GUI mode for reliable CI execution
JMeter in CI and reporting
Raw JMeter XML output is unreadable by humans — turning it into dashboards and CI gates is what makes perf testing a first-class part of delivery.
You'll learn to
- Run JMeter from a Jenkins pipeline or GitHub Actions workflow
- Generate the HTML dashboard report from a .jtl results file
- Stream JMeter results to InfluxDB and visualise in Grafana
- Set error-rate and latency gates that block a deployment on regression
Distributed load generation
OptionalA single machine saturates its own network card before it saturates the server — distributed testing removes the injector as the bottleneck.
You'll learn to
- Configure JMeter in controller/subordinate mode across multiple machines
- Split virtual-user load across agents and aggregate results
- Estimate injector capacity needed to achieve a target concurrency level
- Collect combined reports from all agents into a single dashboard
Diagnosis, baselines, and CI gates
Collecting results is the easy part. Knowing what they mean — and turning them into a regression gate — is the job.
Reading and diagnosing results
Most performance engineers can generate charts. Fewer can point at a chart and say exactly which layer is the bottleneck.
You'll learn to
- Distinguish CPU-bound, memory-bound, I/O-bound, and network-bound bottlenecks
- Use APM traces to identify a slow query or downstream service call
- Separate client-side think time from server-side processing time in results
- Write a concise performance test report that stakeholders can act on
- Reproduce a performance bug in a lower environment
Baselines and performance gates
A performance test without a gate is a measurement without a consequence — baselines give you the comparison point, gates give you the power to block a regression.
You'll learn to
- Record a performance baseline from a known-good build
- Define threshold rules (p95 latency, error rate, RPS) that auto-fail CI
- Use capacity planning data to size infrastructure for projected growth
- Schedule separate soak and breakpoint tests outside the PR pipeline
- Review and update baselines whenever the service changes significantly