R7: add a VPS/VDS sizing table (min/avg/max) to the trip report
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 9s
CI / integration (pull_request) Successful in 13s
CI / ui (pull_request) Successful in 36s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 57s
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 9s
CI / integration (pull_request) Successful in 13s
CI / ui (pull_request) Successful in 36s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 57s
A practical single-host ordering guide — CPU cores, RAM, disk at three tiers — grounded in the R7 profile (~5.5 cores / ~2.5 GiB peak at 500 players) and the measured on-disk footprint (images ~2.4 GB; Tempo 3.1 GB at 72 h; the game DB 23 MiB and growing). Notes which knobs move disk (Tempo/Prometheus retention, Postgres growth) and that the gateway scales horizontally past one host.
This commit is contained in:
@@ -172,6 +172,33 @@ prod contour env (the same compose, `PROD_*` values):
|
||||
safe); pin `GOMAXPROCS` to each CPU limit; keep json-file rotation.
|
||||
- Memory is not the constraint anywhere; CPU is.
|
||||
|
||||
### VPS / VDS sizing (single-host contour)
|
||||
|
||||
The whole contour (the app + the observability stack) runs on one host via
|
||||
`docker-compose`. The tiers below are grounded in the R7 profile (**≈5.5 cores / ≈2.5 GiB
|
||||
RAM peak at 500 concurrent players**; ≈0.5 GiB idle) and the **measured** on-disk
|
||||
footprint: prod images ≈2.4 GB; the Tempo volume **3.1 GB at 72 h** retention; Prometheus
|
||||
≈1–2 GB at 15 d; the game DB 23 MiB and growing with history. CPU and disk grow; RAM has
|
||||
the most slack.
|
||||
|
||||
| tier | CPU | RAM | disk | handles |
|
||||
|------|-----|-----|------|---------|
|
||||
| **Minimum** | 2 cores | 2 GiB | 20 GiB | ~up to ~150 concurrent; lower the compose limits (gateway 1.5 / backend·postgres 1 / tempo 1 GiB) to fit the box |
|
||||
| **Average** (reasonable load) | 4 cores | 4 GiB | 40 GiB | ~300–400 concurrent comfortably; the tested 500 with occasional gateway burst-throttling |
|
||||
| **Maximum** (worry-free) | 8 cores | 8 GiB | 80 GiB | 500+ concurrent with full gateway burst headroom (its 3-core cap) + room to grow; the compose limits fit as-is |
|
||||
|
||||
- The per-service limits in `docker-compose.yml` are tuned for the **Average/Maximum**
|
||||
target (the gateway alone caps at 3 cores). On the **Minimum** tier, scale them down to
|
||||
match the host or the caps over-subscribe it.
|
||||
- **Disk is dominated by observability retention + DB growth.** Tempo (72 h traces) and
|
||||
Prometheus (15 d metrics) are the main levers — shorten the windows (or move Tempo to
|
||||
object storage) to cut disk; Postgres grows with game history, so budget for months of
|
||||
it; container logs are already capped (json-file 10m × 3 ≈ 30 MiB each).
|
||||
- **RAM** rarely binds: the contour peaks ≈2.5 GiB at 500 players and the sum of all
|
||||
configured limits is ≈5.6 GiB, so 8 GiB never strains.
|
||||
- Beyond one host's worth of players, scale the **gateway horizontally** (it is
|
||||
connection-CPU-bound) rather than ordering an ever-bigger box.
|
||||
|
||||
## Re-running
|
||||
|
||||
See [`README.md`](README.md). Briefly, from the repo root:
|
||||
|
||||
Reference in New Issue
Block a user