Capacity planning ⚡ (elective)
Purpose: Size an AEM platform from workload numbers instead of vendor t-shirt sizes.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Architects / platform engineers | Sizing exercises |
⚡ Elective — for platform sizing moments
Inputs to gather first
| Input | Why it dominates |
|---|---|
| Peak page views/sec + cache hit ratio | Uncached RPS = what publish must actually render |
| Render cost p95 per page family | Threads × time = publisher capacity |
| Content volume (pages, assets, growth/yr) | Repo size, index size, backup windows |
| Author concurrency + workflow/DAM ingest volume | Author sizing |
| Invalidation frequency | Cold-cache exposure |
The publish math (order-of-magnitude model)
uncached_rps = peak_rps × (1 − hit_ratio) e.g. 500 × 0.08 = 40
threads_used = uncached_rps × render_seconds_p95 40 × 0.4 = 16 threads
per publisher ≈ healthy at ~60% of its render pool pool 32 → ~19 usable
instances = ceil(threads_used / usable) + 1 (deploy headroom) → 2 (+1)
then re-run at COLD cache (hit_ratio 0) for the flush/deploy case → this usually sets NThe cold-cache row is the real sizing constraint on invalidation-heavy sites — see the matching load-test scenario.
Storage & memory rules of thumb
- Repo disk: current size × growth, ×3–5 headroom for revisions/compaction; fast SSD only.
- Heap: enough that Oak caches breathe (monitor cache hit stats), not so big GC pauses hurt — tune from GC logs, not folklore.
- Datastore: assets dominate; lifecycle rules for renditions; shared blob store dedupes across instances.
- Indexes grow with content and are rebuilt occasionally — budget disk + rebuild time (index management).
Validate, then re-validate
A sizing model is a hypothesis; the load test at production content volume is the experiment. Re-run the numbers at every major traffic event, content migration, or feature that moves the cache hit ratio (personalisation!).