Minecraft
Choose a game-server CPU using evidence from your workload
Compare game-server CPU options with representative workloads, tick evidence and practical questions about shared resources.
Choose a game-server CPU by checking where your game spends its processing time. A model name, core count or advertised clock speed gives you part of the specification. It does not tell you how your particular world, mods and busy sessions will behave on the service you buy. Bring evidence from a representative workload to the comparison.
Write down the workload before comparing hardware
Record the game and server build, software or mod loader, installed content and a few demanding activities. Players exploring new terrain create different work from players standing together in an established base. Background map renders and scheduled jobs also belong in the record. Keep the activity description beside the player count.
Choose the symptom you want to improve. Delayed simulation, a slow join and poor network latency need different checks. Our Minecraft tick and profiler guide helps separate processing evidence from a vague report of lag. For another game, use its own developer-supported measurements rather than applying Minecraft's tick targets to it.
Find out whether extra cores address the busy work
On a conventional Minecraft server, the tick loop contains work that must finish before the next tick proceeds. The spark project's tick-loop explanation describes the normal 20-tick target and the associated 50-millisecond tick budget. Extra cores cannot automatically divide every sequential part of that work.
Other work can run on other threads, and different server implementations have different threading models. Avoid turning “Minecraft likes single-core speed” into a promise about every plugin, mod loader or game. Inspect the actual busy thread and task before deciding whether to prioritise faster execution of that task, additional parallel capacity, or a software change.
A host's overall CPU percentage can also hide the detail you need. Ask what the displayed percentage measures and how the plan defines a core or CPU limit. A vCPU allocation is not a statement that you exclusively own a whole physical processor. Request the relevant scheduling and sharing policy instead of inferring it from the plan name.
Compare the same activity on each candidate
Ask about a supported trial or an operator-assisted comparison before arranging a move. Use an isolated copy of the same world with the same software, content and settings. Keep the original service authoritative so two writable copies do not collect different player progress.
Use the same short activity script on each candidate: the same route through established terrain, the same representative production area and a separately identified exploration test. Record the observation window, participating players, server build and any background jobs. Let startup work settle before the comparison, and repeat at a second representative period.
For supported Paper builds, Paper's profiling guide explains how to collect a spark report while the issue occurs. Keep the report private if it reveals information you do not want to publish. Compare relevant tick-time distributions and the expensive work identified, not just one best-looking screenshot.
A measured illustration of CPU time and elapsed time
On 9 November 2026, CloudExa recorded an isolated Node.js 22.22.0 loopback HTTP fixture under a 25% CPU quota and 256 MiB memory limit. It handled 15 sequential requests, each performing 25,000 PBKDF2-SHA256 iterations. This ran no Minecraft code and compared no processors.
The median measured CPU time was 2.612 ms; median elapsed time inside the request handler was 2.625517 ms. One handler recorded 86.059742 ms elapsed and 2.706 ms CPU time. The elapsed measurement covered the handler's work, not a player's network round trip.
Node's CPU-usage reference explains the process CPU counter used here. These observations illustrate why we retain both CPU and elapsed measurements. They do not isolate the cause of an outlier, benchmark a CPU architecture or predict Minecraft tick time. The temporary fixture stopped after collection. Use a representative game profile for the buying decision.
Illustrative decision: a busy community hub
Imagine an illustrative community whose hub becomes slow during an event. The organiser initially asks for more cores. They first record an event-like session and inspect the expensive work. This is a decision example, not a benchmark result from a CloudExa customer.
If a recurring plugin task occupies much of the affected tick, the organiser can investigate that plugin with its developer before buying capacity around the problem. If a controlled trial on another CPU improves the same activity under the same settings, they have evidence for that particular move. Neither result establishes a universal player limit or a ranking for every game.
If the game pauses while waiting for another service, a CPU upgrade may leave that wait intact. Keep database, disk and network evidence beside the profile. Do not label time in a stack trace as processor execution without checking what the task was doing.
Ask purchasing questions you can verify
Request the CPU model or allocation policy for the service being offered, whether resources are shared, how sustained limits work and what happens if your workload outgrows them. Confirm region and memory separately. An answer about the provider's newest machine does not identify the processor assigned to your order.
Keep a written acceptance test and a migration recovery point. Use the Minecraft migration checklist when planning the data move, and retain a completed backup before changing the active service. Repeat the same busy activity after cutover and compare with your original record.
Buy against the improvement you can demonstrate for your world. If there is no safe comparable trial, ask support to interpret the existing evidence and state that limitation in the decision. A clear uncertainty is more useful than an unverified performance promise.
