PRF-101 · Performance Engineering
Performance Methodology & the USE Method
A repeatable process for performance investigation, so you stop tuning things that were never the bottleneck.
Who this course is for
Engineers and SREs who are handed 'it is slow' and need a repeatable way to find the actual bottleneck instead of tuning whatever was measured first.
Prerequisites
Course outline
Day 1 — A method, not a bag of tricks
- Why ad-hoc tuning fails: the streetlight effect and confirmation bias
- The USE method: utilisation, saturation and errors for every resource
- Workload characterisation before optimisation: what is actually being asked of the system
- Resource-by-resource checklists: CPU, memory, I/O, network
- Latency vs throughput and why optimising one hurts the other
Day 2 — Working an investigation
- First-response triage: a time-boxed checklist for a degraded system
- Drill-down analysis: from symptom to subsystem to root cause
- Building hypotheses that a measurement can reject
- Knowing when to stop: diminishing returns and the cost of the next percent
- Writing up an investigation so the next engineer can follow it
Hands-on labs
Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach
- Lab: characterise an unknown workload from live counters — infer what it does before being told
- Lab: build a USE checklist for a supplied server and rate every resource for utilisation, saturation and errors
- Lab: run a time-boxed triage drill against a VM with an injected fault; find the failing resource inside the window
- Lab: take a tuning folklore claim, design the measurement that would reject it, and run it
Capstone project
Investigate a degraded multi-service VM from the symptom 'users report slowness' to a root cause you can defend: apply the USE method resource by resource, keep a written log of hypotheses and the measurements that rejected or confirmed each, and finish with a one-page report — root cause, evidence, recommended fix, and the point at which further investigation stops paying.
What you leave with
- A repeatable investigation process that survives pressure and unfamiliar systems
- A personal first-response triage checklist tested against injected faults
- The habit of workload characterisation before any tuning
- A written report format that makes your reasoning auditable
How it runs
Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.
Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.
Questions
Who is this course for?
Engineers and SREs who are handed 'it is slow' and need a repeatable way to find the actual bottleneck instead of tuning whatever was measured first. It sits at practitioner level within the Performance Engineering track.
What do I need to know already?
Specific prerequisites for this course: Solid Linux command line; Basic familiarity with vmstat, iostat and top; Some exposure to a production service or system under load. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.
Can this run privately for my team?
Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.
What is the difference between in-person and online?
In person is 2 full days with hardware on your desk, capped at 14. Online is 4 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.
Do you invoice companies?
Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.
Upcoming dates
| Dates | Where | Seats | Early bird | Regular | |
|---|---|---|---|---|---|
| 1 Nov – 2 Nov 20262 full days | RiyadhIn person · KAFD Conference Centre | 4 of 14 | — | SAR 5,250 | |
| 1 Nov – 2 Nov 20262 full days | Kuwait CityIn person · Al Hamra Tower | 9 of 14 | — | KWD 430 | |
| 8 Nov – 9 Nov 20262 full days | MuscatIn person · Knowledge Oasis Muscat | 4 of 14 | OMR 490until 9 Oct | ||
| 15 Nov – 18 Nov 20264 half-days | Gulf bandLive online · 09:00–13:00 GMT+3 | 12 of 20 | US$900until 16 Oct | ||
| 16 Nov – 17 Nov 20262 full days | OttawaIn person · Kanata North Tech Park | 9 of 14 | CAD 1,710until 17 Oct | ||
| 16 Nov – 17 Nov 20262 full days | TorontoIn person · MaRS Discovery District | 4 of 14 | CAD 1,710until 17 Oct | ||
| 16 Nov – 19 Nov 20264 half-days | Europe bandLive online · 09:00–13:00 CET | 17 of 20 | US$900until 17 Oct | ||
| 23 Nov – 24 Nov 20262 full days | LondonIn person · Shoreditch Works | 9 of 14 | GBP 980until 24 Oct | ||
| 23 Nov – 26 Nov 20264 half-days | Americas bandLive online · 13:00–17:00 ET | 6 of 20 | US$900until 24 Oct | ||
| 30 Nov – 1 Dec 20262 full days | BerlinIn person · Factory Görlitzer Park | 4 of 14 | EUR 1,160until 31 Oct |
Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.
More in Performance Engineering
PRF-1102 days
Benchmarking Without Fooling Yourself
Producing performance numbers that survive scrutiny, including your own six months later.
Practitioner-taught
SAR 5,250Next 11 Oct
PRF-2013 days
CPU & Scheduler Tuning
Getting the scheduler out of your way: placement, priorities, frequency scaling and isolation.
Practitioner-taught
SAR 9,000Next 22 Nov
PRF-2103 days
Memory & TLB Optimisation
Memory-bound workloads: huge pages, NUMA placement, allocator behaviour and reclaim pressure.
Practitioner-taught
SAR 9,000Next 1 Nov
PRF-2203 days
I/O & Block Layer Tuning
Storage performance from the filesystem to the device queue, including NVMe specifics.
Practitioner-taught
SAR 9,000Next 18 Oct
PRF-2303 days
Network Stack Tuning
Getting throughput and latency out of the kernel network path, and knowing when to leave it.
Practitioner-taught
SAR 9,000Next 15 Nov