Dedicated Server Spec Table: Survival, FPS, MMO, and Web Hosting Workloads Compared

Picking a processor by core count alone is how game hosts end up with 32 cores idling at 8% while a 64-player server stutters every time a chunk loads. Different workloads stress completely different parts of the machine. A survival server cares about one hot thread and heap headroom, a competitive FPS server cares about tick jitter on a fixed core set, an MMO cares about database write latency under a persistent player graph, and a web host cares about concurrent request throughput with cache misses. The table below sets a floor for each.

Every number here assumes a rented bare-metal box from a host that exposes real hardware, not a resold VM. If you have not confirmed what the chassis actually contains, start with the dedicated server plans with published CPU and NVMe specs and compare the part numbers before you compare the price. Clocks, per-core memory, and queue depth matter more than the marketing tier name on the order page.

Why one spec sheet cannot cover four workloads

Survival and FPS servers are latency-bound on a single simulation thread. Their bottleneck is the 16.6 ms frame budget at 60 ticks per second, of which the game logic may consume 9 ms, leaving 7 ms for save flushes and network. MMO servers are write-bound, because every inventory change and trade is a durable database transaction. Web hosting is request-bound and benefits from many threads, a large page cache, and fast random reads.

That difference shows up in hardware rankings. A 3.2 GHz 16-core Xeon Silver will lose to a 4.5 GHz 8-core Ryzen on a Valheim world with 2000 build pieces, then win decisively as an nginx and MySQL node serving 4000 requests per second. The spec table has to be per-workload, or it is just a shopping list.

Survival servers: clock floor and heap headroom

The floor for Valheim, 7 Days to Die, Icarus, Enshrouded, and Palworld is 4.0 GHz sustained all-core, with a boost of at least 4.8 GHz on the two threads handling world simulation. Below 3.6 GHz sustained, save-and-load cycles stretch past 90 seconds on a 4 GB world and players see the classic freeze every time a distant base enters the loaded region. Memory per instance runs 2.5 to 4 GB for a 10-player vanilla world and 6 to 10 GB for a modded 20-player world.

Those per-slot figures are not the same as total RAM. A 48-slot server at 450 MB per slot needs 21.6 GB of heap, plus 4 GB for the OS, 3 GB for page cache during save, and a 15% margin, which lands on 32 GB. Under-provisioning here produces the out-of-memory kill at 03:00 during the automated backup.

Competitive FPS: tick budget and per-core isolation

CS2, Squad, Hell Let Loose, and Battlefield-style dedicated servers run a 64-tick simulation that must complete inside 15.6 ms, with 128-tick at 7.8 ms. A single core must hold that budget while the OS handles interrupts and network softirq. The practical floor is 4.2 GHz with a 4.8 GHz boost, and the box needs at least two physical cores per instance reserved: one for the tick loop, one for networking and anticheat.

NVMe requirements here are modest, 20k to 40k random read IOPS, because the map is loaded once and stays in page cache. What matters is not throughput but consistency. Look for a drive with 99th-percentile read latency under 300 microseconds at QD1, since the tick loop issues small synchronous reads during round transitions. A cheap QLC drive with a 2 ms p99 will produce a visible hitch at map change even though its sequential benchmark reads 3 GB/s.

MMO and persistent world servers: write latency and connection count

An MMO shard holds a persistent player graph, auction house, and guild bank in a database that must commit every transaction durably. The budget is 2 to 5 ms per commit on NVMe with a battery-backed or PLP-equipped controller. Queues above 8 ms during a boss encounter show up as item duplication or lost loot, which is a support ticket storm rather than a lag complaint.

• Clock: 3.6 GHz sustained is enough, 4.0 GHz preferred for zone loading.
• RAM: 6 to 12 GB per 1000 concurrent connections for the auth and world layer.
• NVMe: 400k mixed IOPS minimum, 1 DWPD endurance class, over-provisioned 10%.
• Uplink: 1 Gbps unmetered per 800 to 1200 players, with a 10 Gbps port for login storms.

Connection count drives conntrack table size as much as bandwidth. A 5000-player launch with a 30-second login retry can briefly open 40k simultaneous TCP sessions, so set nf_conntrack_max to 262144 and size the NIC ring buffers accordingly before the first player connects.

High-traffic web hosting: threads, not clocks

WordPress and WooCommerce nodes serving 3000 requests per second want 16 to 32 threads at 3.2 to 3.6 GHz, 64 to 128 GB of RAM for the page cache and PHP-FPM pool, and NVMe that sustains 300k random 4K reads at QD32. Clock speed matters far less here than core count once you pass 8 workers, because request handling is parallel and mostly waiting on the database.

Storage sizing follows the working set. A 200 GB database and 60 GB of media benefits from 128 GB of RAM only if the hot working set fits; otherwise you are paying for cache that never fills. For peak sale days, budget 2 GB of RAM per PHP-FPM worker at 60 concurrent children, plus 24 GB for MySQL InnoDB buffer pool on a 200 GB dataset.

How to map a plan to the table

Ask the host for the exact CPU SKU and base clock, not the family name. “EPYC” covers 2.0 GHz 32-core parts and 3.7 GHz 16-core parts, and the difference decides whether your survival server runs at 20 TPS or 9. Then check the NVMe model and whether it is enterprise with power-loss protection. A consumer drive labelled NVMe is the most common spec-sheet lie in this market.

Finally, confirm the uplink is dedicated rather than shared. A 1 Gbps port that is oversubscribed 4:1 at the switch will drop your 128-tick server to 40 players during regional peak, regardless of CPU. Bring the workload table, three questions about CPU SKU, drive model, and uplink contention, and a lunch break’s worth of paperwork to the sales call.

Matching capacity to expected player curve

Plan for the launch-week peak, not the steady-state average. A survival server that hosts 18 players on a Tuesday can spike to 60 on a content patch day, and a 32 GB box that was comfortable at 18 slots will thrash at 60. Add one full RAM tier of headroom above the expected peak, and keep the CPU two SKUs above the floor so a single-thread regression in a game patch does not push you over the tick budget.

If you run more than one game on the same chassis, sum the reserved cores rather than the average load. Three servers each using 40% of two cores still need six cores, because the tick loops collide on the same physical cores at the same millisecond. Pinning each instance to its own CCX is the cheapest way to keep the spec table honest.

Budget allocation by workload

Spend the money where the workload is weakest. Survival and FPS hosts should put 50% of the budget into CPU clock and platform quality, 25% into RAM, and 25% into network. MMO operators should shift 40% to NVMe endurance and controller quality. Web hosts should shift 40% to RAM and only 20% to CPU, because cache hit rate moves the needle more than another four cores.

When you are ready to compare actual configurations against these floors, review the bare-metal server configurations available for game and web workloads and hold each one against the row that matches your game. The plan that clears its row with 20% headroom is the one that survives the first content patch.