3 / 6
k6 load testing

Diagnose a performance bottleneck

Hard120 pts~45 min
  • Bottleneck analysis
  • Comparative load
Practice app · Checkout Service

A load-testable checkout service with realistic latency that degrades under concurrency, plus a live metrics view.

BASE_URL
/api/practice
Console app
/lab/sdet-diagnose-a-performance-bottleneck

Your starter code already declares BASE_URL — call the API relative to it.

Objective

Load two endpoints side by side and identify which one degrades with concurrency.

Your task

  1. 1Set options { vus: 10, iterations: 60 }.
  2. 2In group('search') GET /perf/search?q=mug; in group('checkout') GET /perf/checkout.
  3. 3check each: status 200 and per-endpoint budgets (search < 300 ms, checkout < 1200 ms via res.timings.duration).
  4. 4Write your conclusion in a comment: which endpoint is the bottleneck and why (latency grows per in-flight request).

Acceptance criteria

  • Search and checkout return 200
  • Requests are grouped per endpoint
  • ≥ 100 requests are sent
  • At least 100 check() calls pass

k6 load testing · SDET · Scaling & analysis