More Cores Will Not Fix Your Server

A sixteen-core server will not run your game better than an eight-core one. In most cases it will run it identically, and you will have paid roughly twice as much to find that out.

This is the most expensive misunderstanding in game server hosting, and it persists because every hosting page in the industry advertises core count in large type and clock speed in small type, if at all.

What the game is doing

A game server simulates a world on a fixed schedule. Twenty times a second, or sixty-four, or a hundred and twenty-eight, it works out where everything is, resolves what happened since the last time, and sends the result to everyone connected.

That loop is sequential. Each step depends on the one before it, because you cannot resolve a collision before you know where things moved. Sequential work runs on one core.

So the question that determines whether your server feels good is not how many cores you have. It is how fast one of them is, because the tick has to finish inside its budget and only one core is working on it.

At 64 ticks per second the budget is about 15 milliseconds. Miss it and the server falls behind, which players experience as rubber-banding, delayed hit registration, and the general sense that something is wrong that no amount of pinging will explain. Tick rate explained covers what the number means; the hardware consequence is that a fast single core is the thing keeping you inside the budget.

Which games are worst affected

Minecraft is the clearest case. The main tick is single-threaded by design, and adding cores does nothing for it. A Minecraft server on a modern high-clock consumer chip will comfortably outperform the same server on an older sixteen-core workstation part, and the workstation part will cost more.

Source-engine games are the same shape. The simulation runs on one thread; networking and a few auxiliary tasks use others, but they are not what falls behind.

Rust and other Unity-based survival games parallelise more, and still have a dominant main thread that sets the ceiling.

FiveM is the most extreme version. Every script resource competes for time on the same thread, which is why fixing FiveM server lag does more for performance than any hardware upgrade.

What extra cores are for

They are not useless. They are just not doing what the marketing implies.

Chunk generation, world saving, compression, backups, and anything the game has offloaded to a worker thread will use them. On a Minecraft server, world generation on a spare core is the difference between a stutter when someone explores and no stutter.

They also let you run more than one thing on the machine. Two servers, a database, a voice server, a web panel. This is the honest case for more cores: not a faster server, but several servers.

How to read a hosting page

Providers rarely publish clock speeds and almost always publish the CPU model, which is enough.

Look the model up and note the single-core boost clock. Anything at or above 4.5 GHz on a recent generation is comfortable for game servers. Anything around 2.4 to 2.8 GHz is a server-room part designed for throughput across many workloads, and it will disappoint you on a game even though it has thirty-two cores.

Two other things worth checking:

Shared or dedicated cores. A VPS advertising "4 vCPU" may be four threads on hardware shared with a dozen other customers. On a quiet host that is fine; on a busy one your tick budget is at somebody else's mercy. Dedicated versus VPS covers the trade properly.

Whether the provider says anything at all about the CPU. A host that names the exact model is a host that expects you to check. One that says "high-performance enterprise hardware" is hoping you will not.

Where the money should go instead

If you have a budget and want the server to feel better, the order is roughly:

First, a faster single core. This is the whole point of the article.

Second, enough memory, and no more. Memory that is not being used does nothing. Buying 32 GB for a twenty-player server is money spent on a number. Hardware specs covers realistic figures.

Third, a fast disk, which matters more than most people expect on any game that saves a world. Hardware specs is a separate discussion and a real one.

Fourth, the network route to your players, which is not a hardware question at all but frequently the thing they will notice most. Routing beats distance.

Cores come after all of that, and only when you are running several things on one box.

The uncomfortable version

Most servers that feel slow are not short of hardware. They are running a plugin doing something expensive on every tick, an entity count that has grown for six months, or a database write in the wrong place.

Upgrading the machine makes those problems smaller without fixing them, and it costs monthly. Profiling a server that feels slow is the alternative, and it is free.

The measurement that settles it

You do not have to take any of this on faith. Two numbers, both free to obtain.

Run the server under load and watch per-core utilisation with htop. What you are looking for is one core near its ceiling and the rest largely idle. That shape is the whole argument: the busy core is your tick, and the idle ones are the capacity you paid for and cannot use.

Then check whether the server is meeting its tick budget. Most games expose this, Minecraft reports milliseconds per tick, Source games have a server framerate figure, FiveM shows resource timings. If the main loop is inside budget while one core sits at 90%, you are near the edge and more cores will not move you away from it.

A shortcut that works surprisingly often: if the server feels worse at forty players than at twenty, and CPU utilisation on the busy core has gone up proportionally while the others have not moved, you have confirmed the diagnosis in about a minute.

When you do need cores

Three cases, and they are all "several things", not "one faster thing".

Running multiple game servers on one machine, which is the common one and a legitimate reason to buy a larger box.

Running a database, a voice server, a web panel and a game server together. Each wants its own slice, and contention between them produces stutters that look like game problems and are not. Databases for game servers covers keeping that separation clean.

Games that parallelise their world simulation. There are a few, mostly newer, and their documentation will say so plainly rather than leaving you to infer it.

Outside those, the money is better spent on the clock speed of a smaller machine, and the difference is usually visible to players within an evening.

What to tell a host

If you are shopping rather than diagnosing, the request is short.

Ask for the CPU model and the single-core boost clock. Ask whether cores are dedicated or shared, and whether they oversell. Those two questions cover almost everything on this page, and a provider who answers them plainly is telling you something about their support at the same time.

Choosing a game server host covers the other four questions worth asking, and the pattern there is the same: the specifications that decide how a server feels are not the ones printed largest.

The exception worth knowing

Everything above assumes a game with a dominant simulation thread, which covers nearly everything in this directory.

A small number of newer titles parallelise their world simulation across cores, and their documentation says so directly rather than leaving you to infer it. If you are running one of those, core count is a real specification and the advice inverts.

The way to tell without reading documentation is the measurement from earlier: run it under load, watch per-core utilisation, and see whether the work is spread or concentrated. A game that spreads it will show several cores busy at once. Almost none do.

The summary

Buy clock speed. Buy enough memory and no more. Buy a fast disk. Check the route to your players.

Buy cores when you are running several things on one machine, which is a real reason and a different one from making a single server faster.

And before buying anything, profile. The overwhelming majority of servers that feel slow are running one thing badly rather than running on inadequate hardware, and no amount of money fixes a plugin doing work on every tick.

If you have already bought the wrong thing

It happens, and it is usually recoverable without moving.

Check first whether the machine is the constraint. Run the per-core measurement above; if the busy core is not near its ceiling, the hardware is not what is limiting you and moving will not help. Most servers in this position have a plugin or an entity problem instead.

If the core is saturated, the cheapest fix is frequently to reduce the work rather than to buy more machine, fewer entities, a shorter view distance, a pruned plugin list. profiling before you buy anything covers finding the expensive thing, and it is free.

Moving host is the last resort, and the migration sequence is worth reading before you start rather than during.