Skip to lesson
Exit
Capstone: Mock Loop & Self-Exam1 / 2

1 min lesson

Task 1 - p95/p99 latency by model and client version

Walk through the worked example in "Task 1 - p95/p99 latency by model and client version", then explain what it demonstrates.

Step 1 of 2

Task 1 - p95/p99 latency by model and client versionthe warm-up; do not average

The trap is reaching for AVG(latency_ms). Latency is heavy-tailed, so the mean is dragged by the tail and hides the slow experiences that actually frustrate users. Report percentiles, segmented.

p50/p95/p99 completion latency by model x client_version
SELECT
  model,
  client_version,
  COUNT(*)                                              AS n,
  PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY latency_ms) AS p50_ms,
  PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency_ms) AS p95_ms,
  PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY latency_ms) AS p99_ms
FROM interaction_events
WHERE event_type = 'success'           -- only completed interactions have a real latency
  AND latency_ms IS NOT NULL
  AND ts >= NOW() - INTERVAL '7 days'
GROUP BY model, client_version
HAVING COUNT(*) >= 200                  -- suppress percentiles on thin segments
ORDER BY p99_ms DESC;
Say it like this

“I'm filtering to successful interactions because a timed-out request has no meaningful completion latency and I'm using PERCENTILE_CONT instead of an average because latency is heavy-tailed. I added a HAVING floor so a segment with twelve rows doesn't post a noisy p99 next to one with twelve thousand.”