CPU Clock vs Core Count: What Game Servers Actually Need

Buy clock speed, not core count. Almost every game server simulates its world on a single thread, so a 6-core desktop chip at 5.1 GHz will out-tick a 32-core server CPU at 2.1 GHz on the same map. Extra cores only start paying you back when you run several servers on one machine.

Published 25 September 2026 · JoinGG · Guides

The short answer, and the one case where it flips

The most expensive mistake in game server hardware is paying for cores. Core count is the number every host prints in the biggest font, and for web workloads, build farms and databases it is the right number to read. Game simulation does not scale that way, for structural reasons rather than a bug someone will fix. The clock speed of one core, and how much of that core you actually get, decides whether your world holds a full 20 ticks per second under load.

Put numbers on it. A Minecraft server has 50 milliseconds to finish one tick. Inside that window it moves every entity, runs every scheduled block update, resolves redstone, fires plugin listeners, and builds the packets for every connected player. If that work takes 60 ms, the server drops to roughly 16.7 ticks per second and everything slows proportionally: hoppers move fewer items, mobs path more slowly, player movement starts fighting rubber-band correction. A Source engine server at tickrate 64 has 15.6 ms per frame, and at 128 it has 7.8 ms. None of those budgets get larger because you added cores.

So a 32-core Xeon running at a 2.1 GHz base clock, which is a completely normal machine to find behind a cheap VPS plan, gives you 32 copies of a slow lane. A current 6-core or 8-core desktop chip boosting to 5.1 GHz gives you six or eight copies of a fast one. For a single Minecraft world the desktop chip finishes the tick in roughly half the time, and you can watch the difference on a tick graph: same world, same plugin set, same player count, two MSPT baselines that do not overlap.

The case where this flips is narrow but real. Run eight separate worlds and each one gets its own main thread, so eight slow lanes beat six fast ones. That is the whole exception, and the rest of this guide is about telling the two situations apart before you sign up for twelve months.

Why does a game server tick on only one core?

Because a tick is an ordered simulation step, and the order is load-bearing. Entity A moves, then the collision check that depends on A's new position runs, then the block it landed on fires its update, then the hopper under that block pulls an item, then the comparator reading that hopper changes state. Each step mutates shared world state that the next step reads, so splitting them across threads means locks covering almost every object in the world.

This is not laziness. Minecraft's world is one large mutable object graph, and the granularity at which you would have to lock it, roughly per chunk or per region, produces contention that costs more wall-clock time than the parallelism saves. The one serious attempt at region-based threading, Folia, only helps when players are far enough apart that their regions never touch. Sixty players in one spawn town is a single region, which is a single thread, which is where you started.

Source and GoldSrc are worse, not better

Source engine servers run the same pattern with an extra cost bolted on. Each frame the server simulates physics and entity think functions, then builds a delta snapshot for every connected client. Snapshot construction scales with player count and with how much of the map each player can see, and in the shipped dedicated server binaries it sits on the simulation thread. GoldSrc, which Counter-Strike 1.6 still runs on, is strictly single-threaded end to end.

FiveM concentrates everything on one thread by design

On FiveM roleplay servers the situation is sharper still, because the main thread is not just the engine, it is your entire codebase. Every ESX or QBCore module, every job script and every event handler runs on that one thread, so a single synchronous MySQL query inside a loop freezes the server for as long as the database takes to answer. That is why oxmysql and its async patterns exist, and why a server stuttering at 40 players is almost never short of CPU.

What actually runs on the other cores

The main loop being single-threaded does not mean a second core is wasted. It means the second core does a different job. On a modern Paper server the split is roughly this:

• Chunk generation and chunk I/O. This is the big one. Paper moved terrain generation and region file reads onto worker threads, and on a fresh world those workers can saturate three or four cores while the tick thread stays comfortable. It is why a box that feels fine on an established map chokes when a player runs 5,000 blocks into unexplored terrain.

• Garbage collection. G1 and ZGC both use parallel worker threads. Given real cores, GC runs alongside the tick and you never notice it. On a 2 vCPU box, GC and the tick thread take turns and your MSPT graph grows a sawtooth.

• Network. Netty runs event loops sized from the available processor count. Packet encryption, compression and socket handling all happen off the tick thread.

• Region file compression and backups. Zlib on save, plus whatever your backup script does at 04:00. Both are trivially parallel and both fight the tick thread if nothing is spare.

• Separate server processes. A Velocity proxy, a web panel, a MariaDB instance and a Discord bot are four independent workloads that genuinely want their own cores.

Which server software you run changes how much of this is true. Vanilla and Spigot do far less asynchronous chunk work than current Paper, and Fabric depends on which performance mods you have loaded. Read the comparison of Paper, Purpur and Fabric before you decide hardware is the problem: switching from Spigot to Paper on identical hardware routinely buys back 20 to 40 percent of tick time. Software first, then hardware.

The practical upshot is a shape rather than a number. Four to eight fast cores covers a single busy server with room for GC, chunk workers and a proxy. Going from eight to sixteen buys almost nothing for that one server.

Threading behavior by game, and the spec that moves the needle

Threading behavior varies more than most buying guides admit, and it varies in ways that change what you should spend money on. The table below covers the games that carry real server populations on the live server list, which as of the most recent sweep tracked 11,561 listed servers across 31 games with servers up.

Two patterns fall out of that table. First, the older the engine, the more brutally single-threaded it is, which is why a CS2 community server and a 1.6 server want almost the same thing from a CPU despite twenty years between them. Second, the survival games are the only entries where RAM capacity competes with clock speed for your budget, because a mature Rust server holds an enormous entity count in memory and a wipe-day save can take tens of seconds to serialize.

What does 4 vCPU actually buy you on a shared host?

A vCPU is a hardware thread scheduled by a hypervisor onto a host you share with other tenants. The listing says four. What you have is four claims on a machine that may have sold those cores five or eight times over. An oversubscription ratio between 3:1 and 8:1 is normal on budget plans and not dishonest, because most tenants idle. Your game server does not idle. It wakes up twenty times a second forever.

The number that exposes this is steal time. Run top or vmstat 1 and read the st column: the percentage of time your vCPU was ready to run and the hypervisor gave the core to somebody else. Sustained steal under 2 percent is fine. Above 5 percent you get periodic MSPT spikes with no matching cause in your own profiler.

Three plan types, and what each one is for

• Shared vCPU. Cheapest and oversubscribed. Fine for a Discord bot, a web panel or a 10-player private world. Not acceptable for anything you advertise.

• Dedicated vCPU. A physical thread reserved for you, at roughly two to three times the price of a shared plan at the same core count. The correct default for a public server.

• Burstable with CPU credits. A baseline of 20 to 40 percent of a core, with credits that let you exceed it briefly. A trap for game servers: you pass every test during setup, then throttle to baseline on your first busy evening, at exactly the moment you have an audience.

Two more checks before you pay. Ask which CPU model the plan runs on, because a Ryzen 9 7950X or an EPYC 4584PX is a selling point and a host that will not tell you has told you. And treat advertised boost clocks as fiction on shared hardware: a chip rated to 4.7 GHz single-core will not hold anything close to that with every core carrying tenants. The breakdown of what game server hosting actually costs shows whether a price implies dedicated cores or a crowded host.

The single number to compare before you pay

Single-thread performance. Not core count, not total TDP, not aggregate multi-core score. If you are comparing two machines and you only get one number, make it PassMark's single thread rating, Cinebench single-core, or Geekbench 6 single-core, and compare the same benchmark across both.

Rough bands, for calibration rather than precision. An older datacenter chip in the 2.1 to 2.3 GHz range, the kind that fills cheap VPS fleets, lands around 1,500 to 2,000 on PassMark single thread. Mid-generation server silicon sits around 2,200 to 2,800. A current mainstream desktop chip lands between 4,200 and 4,900. That is a factor of two to three, and it maps almost linearly onto tick time for the same workload. Halve the single-thread score and a 25 ms tick becomes a 50 ms tick, which is the exact edge of the cliff.

One caveat on benchmark choice. Game server main loops are branchy, pointer-chasing, integer-heavy code that spends its life waiting on memory. Cinebench is a floating-point render, which flatters chips with wide vector units in a way that does not transfer. Geekbench integer subscores and PassMark single thread correlate better with real tick behavior. This is also why memory matters more than people expect: chasing references across a 12 GB Java heap is latency-bound, so DDR5-6000 at CL30 genuinely outperforms registered DDR4-2400 at the same core count, and the effect shows up in MSPT.

The honest test, if a host offers a trial or an hourly plan, takes about an hour. Order the smallest instance on the same hardware family, run a single-thread benchmark, check steal time under vmstat, then upload a real pregenerated world with your real plugin list and watch MSPT with Spark for twenty minutes. Synthetic numbers tell you the ceiling; the world tells you the floor. The hardware spec guide covers the RAM and disk side of the same shopping trip.

When core count genuinely matters

There is a clean rule here: cores buy simultaneous independent workloads, never faster single ones. Name eight things that must run at the same time without talking to each other and you want eight cores. Name one and you want one fast one. The situations where the count genuinely earns its money:

1. Multiple server instances on one box. Six Paper servers of 20 players each is six independent tick threads. This is the single most common legitimate reason to buy 12 or 16 cores, and it is how most small hosting operations are actually structured.

1. World pre-generation. Chunky and similar tools saturate every thread you give them for hours. Pre-generating a 10,000-block-radius map on a rented 16-core machine and copying the region files to production is a reasonable use of cores for a day.

1. Heavy modpacks with async workers. Some large Forge and Fabric packs push meaningful work onto background threads, and a few mods spawn their own thread pools. This helps less than modpack authors claim, but it is not zero.

1. A colocated database. ESX and QBCore character data, ban tables, economy logs and statistics all hit MySQL. On a busy FiveM population of a few hundred concurrent players across your servers, giving MariaDB its own core or two removes a whole class of stutter.

1. Proxies and fleet infrastructure. Velocity is genuinely multi-threaded, and so is any log shipper, metrics agent or anti-cheat sidecar you run.

1. Backups and compression. A nightly zstd pass over a 40 GB world is embarrassingly parallel and should not be competing with the tick thread.

Notice what is not on that list: more players on one world. Adding players to a single Minecraft server adds work to the one thread that is already the bottleneck. The guide on how many slots to actually open makes the same point from the other direction, and it is worth internalizing before you buy a slot count you cannot simulate.

Three builds: one server, one VPS, one node

Concrete shopping targets, all current as of late 2026, all sized from the same principle.

The home or colocated single-server box

Six to eight current desktop cores boosting past 5.0 GHz, 32 GB of DDR5 at 6000 MT/s, one 1 TB NVMe drive. This runs a 40 to 60 player Paper world with 25 plugins, a Velocity proxy and a MariaDB instance at once, with headroom during chunk generation. The trade-off is your home upload link and your power reliability, both of which are usually the real constraint rather than the CPU.

The VPS shortlist

Four dedicated vCPU on a chip that sustains 3.5 GHz or better, 8 to 16 GB RAM, NVMe storage, and a provider that names the CPU model. This holds 20 to 40 players on a Paper world or a mid-size FiveM server. Refuse burstable plans, refuse anything that will not name the silicon, and check steal time on day one. Location matters as much as specification, so pair this with the guide to picking a hosting region: 60 ms of avoidable latency ruins a server that ticks perfectly.

The multi-server node

Sixteen cores sustaining 4.0 GHz or better, 128 GB RAM, two NVMe drives in RAID 1. This is the box for eight to ten medium servers under Pterodactyl, and the only build here where core count is the headline number. Budget one to one and a half physical cores per active game server plus two for the host itself, and leave 20 percent of RAM unallocated so the page cache can do its job.

Whichever you pick, measure before and after. Record MSPT at your normal peak, change one variable, record again. Tick data settles hardware arguments in a way spec sheets never will, and the Minecraft population data tells you when your own peak is likely to land: the busiest hour measured across all tracked games is Saturday at 18:00 UTC, at 242,719 players.

Frequently asked questions

Does a 32-core server CPU ever beat a fast desktop chip for Minecraft?

Yes, but only when you count servers rather than players. One 40-player world will always tick faster on the desktop chip. Eight separate 20-player worlds will run better on the 32-core box, because each world gets its own core and none of them are fighting for the same six threads. The crossover usually lands somewhere between four and six concurrent instances.

Will adding more cores fix low TPS?

No. If MSPT is above 50 ms, one thread is doing too much work, and a ninth idle core cannot help it. Profile with Spark, read the tick report, and you will usually find a specific cause: an entity farm, a chunk-loading plugin, a synchronous database call, or a mob cap set too high. Fix the workload, not the invoice.

Is hyper-threading or SMT worth paying for?

It is worth having and not worth paying much for. The main loop uses one physical core and gains nothing from its sibling thread. Garbage collection, Netty event loops and chunk workers do benefit, so SMT is typically worth five to fifteen percent on a busy box. Treat a 4 vCPU plan as two real cores when you size it.

How many players can one core handle?

Players are the wrong unit. Tick cost comes from loaded chunks, entities, block updates and plugin work, and 20 players spread across a 10,000 block map cost far more than 60 players standing in one spawn town. Size by entity and chunk load, then confirm with a real MSPT measurement under real traffic.

Should I give the JVM more garbage collection threads?

Usually the opposite. On a 4 vCPU box, G1 will happily spawn more parallel GC threads than you have real cores and then steal time from the tick thread. Cap them with a flag such as ParallelGCThreads=3 and ConcGCThreads=1, keep the heap modest, and measure the pause times rather than guessing.

Does clock speed matter as much for FiveM as for Minecraft?

More, if anything. Every server-side resource you install runs on the same main thread, so one badly written loop in a job script stalls the whole server. Minecraft at least pushes chunk work onto other cores. On FiveM, single-thread performance and database latency are close to the only two hardware numbers that change how the server feels.

Related reading

• The full game catalogue, covering all 147 titles JoinGG tracks and the 31 with live servers.

• Update and patch notes, for the software changes that shift tick cost between releases.

Once the hardware argument is settled, the harder question is whether anyone is playing on the machine you just bought. JoinGG polls every listed server hourly and keeps seven days of history, enough to show whether a change moved your concurrent player count or only your MSPT graph. Browse the live lists, compare against the games you compete with, and put your server in front of people already looking for one.