Load testing
Purpose: Design realistic load tests for a cached platform: scenarios, cache states, and pass criteria.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Backend/platform engineers | Test designers |
| Tech leads | Interpreting results |
The cardinal rule: test the cache states, not just the happy path
A dispatcher-fronted site at 95% hit ratio is nearly infinitely fast — until an invalidation storm. Scenarios:
| Scenario | Simulates | Watch |
|---|---|---|
| Warm cache steady state | Normal traffic | CDN/dispatcher hit ratio, edge latency |
| Cold cache (post flush) at peak | Deploy/flush during campaign | Publish render p95, thread pool, recovery time |
| Invalidation churn | Authors publishing during peak | Stampedes on hot pages, grace handling |
| Uncached-heavy mix (search, AJAX, personalisation calls) | Real user behaviour | Publish CPU, upstream breaker behaviour |
| Author load (electives) | Bulk editing, DAM ingest, workflows | Author responsiveness, queue depths |
Tooling: JMeter/Gatling/k6 all fine; Adobe's Tough Day exercises AEM-internal author patterns. Test through the full chain (CDN → dispatcher → publish) with realistic Host headers and cookie behaviour — bypassing the CDN tests a system users never touch.
Realism requirements
- URL mix from real access logs (top pages + long tail), not five hand-picked URLs.
- Ramp to peak ×2, hold long enough for JVM warmup and GC patterns to show (30+ min holds).
- Content volume at production scale — an empty repo lies about query and index behaviour.
- Include the failure drill: kill a publisher mid-test; break an upstream (resilience).
Pass criteria (pre-agreed, in writing)
Example set: p95 page < 800ms at peak×2 warm; cold-cache recovery < 5 min; zero 5xx above 0.1%; no thread pool exhaustion; hit ratio ≥ 90% steady. Failing criteria block go-live — that is what they are for.