Planning Dedicated Server Capacity Around Player Concurrency Curves

Player concurrency is never a flat line. It spikes at patch launches, weekends, and evening primaries, then falls away for twelve hours at a stretch. Sizing a machine for the peak of that curve means paying all month for capacity used a few hours a week. Sizing for the average means failing exactly when players care most. The practical answer is to model the curve, define a target at the 95th percentile, and design a buffer that absorbs the launch spike without permanent over-provisioning.

Measure the curve before you buy

You cannot plan capacity from a single busy-night number. Collect concurrent-player counts at one-minute resolution for at least two weeks, ideally longer. From that series, compute three figures: the median (your normal load), the 95th percentile (your planning target), and the maximum (your spike, usually a patch day). These three numbers behave very differently and each maps to a different hardware decision.

• Median — sets the baseline machine you should own outright.
• 95th percentile — sets the sizing target; your box must hold tick rate here without strain.
• Maximum — sets the burst plan; either headroom or a temporary second instance.

Most communities find the 95th percentile is roughly 60–75% of the maximum, and the median is 30–45% of it. That gap is where the money is.

Convert concurrency to resources

Each genre has a rough per-player resource cost that lets you translate a concurrency target into cores, RAM, and bandwidth. These are planning estimates, not guarantees — always validate against your own benchmark. The figures below assume dedicated bare-metal hardware and a single game instance.

Genre	Cores @ 95th	RAM @ 95th	Uplink @ 95th
Survival (Valheim, Enshrouded)	0.08/player	90 MB/player	0.09 Mbps/player
Shooter (60Hz tick)	0.10/player	60 MB/player	0.14 Mbps/player
MMO-style sandbox	0.12/player	120 MB/player	0.10 Mbps/player
Building/sim (large bases)	0.09/player	150 MB/player	0.08 Mbps/player

Design the spike buffer

A patch-day spike can double concurrency for an afternoon. Three strategies handle it, and the right choice depends on how often spikes occur.

• Static headroom — buy for the maximum. Simplest, but you pay for idle capacity most of the month.
• Burst to a second instance — run a standby game server on a smaller secondary machine, brought into a proxy pool only for events. Requires a proxy layer from day one.
• Queue and gate — cap the server at a concurrency it can hold and let a lobby queue absorb the overflow. Cheap, but players dislike waiting.

For most community servers the middle option is the best balance. A proxy network lets you add capacity behind a single stable address, so your players never see an IP change. If you are weighing that architecture, the bare-metal hosting planning notes cover how proxy tiers map onto dedicated hardware.

Watch the non-linear cliffs

Concurrency cost is not perfectly linear. Certain thresholds introduce step changes that ruin a tidy per-player model:

• Above a certain player count the server may spawn additional simulation threads, doubling core demand.
• World-size thresholds force larger save files, shifting the bottleneck from CPU to disk write latency.
• Bandwidth shaping kicks in at the switch or uplink level, producing packet loss that looks like CPU lag.

Each of these turns a gradual cost increase into a cliff. When you build the model, mark the player numbers where each threshold sits and treat them as hard ceilings until you migrate to a larger instance. A server running at 58 of a 60-player cliff has far less effective headroom than its percentage utilisation suggests.

Translate the plan into hardware

Once the model is settled, choosing a machine becomes mechanical. Multiply the 95th-percentile target by the per-player figures, round up generously, and add a fixed reserve for the OS, management agents, and backups. A worked example: a survival community targeting 200 concurrent at the 95th percentile needs roughly 16 cores, 18 GB of RAM, and 20 Mbps sustained — so a 24-core, 64 GB box with a 1 Gbps link carries the load with room for the spike layer.

• Round core counts up to the nearest CCD or core complex so pinning stays clean.
• Reserve 15–20% of RAM for cache and system processes.
• Size the uplink for at least 3x the 95th percentile to absorb retransmits and DDoS noise.

Review quarterly, not annually

Concurrency curves drift. A retention push, a streamer mention, or a seasonal event shifts the whole shape. Recompute the median, 95th, and maximum every quarter and compare against your current capacity. If the 95th percentile has crept above 70% of your machine’s comfortable ceiling, start planning the next step before the spike forces your hand. Good capacity planning is a habit, not a purchase — and the operators who treat it that way rarely scramble before a launch night. For worked comparisons of machines against these targets, see the hardware notes at bestdedicatedwebhostingserver.com.