Correlate errors with load
Hard120 pts~45 min
- Error analysis
- Capacity limits
Practice app · Checkout Service
A load-testable checkout service with realistic latency that degrades under concurrency, plus a live metrics view.
Your starter code already declares BASE_URL — call the API relative to it.
Objective
Push concurrency past the service's overload point and relate errors to the number of VUs.
Your task
- 1stages: [{ duration: '4s', target: 5 }, { duration: '6s', target: 35 }, { duration: '3s', target: 0 }].
- 2GET BASE_URL + "/perf/checkout"; check the status is 200 or 503.
- 3When a 503 occurs, log __VU, the current in-flight level if known, and the Retry-After header.
- 4No sleep — keep requests in flight to build concurrency.
Acceptance criteria
- GET /perf/checkout returns 200
- Stages ramp past 20 VUs
- 503 handling is present
- ≥ 100 requests are sent
Constraints
- Runner limits: ≤ 50 VUs, ≤ 400 requests and ≤ 20 s per run — size options accordingly.
k6 load testing · Performance Testing · Scaling & analysis