VPS CPU Benchmarks: Copy a Test That Tracks Steal Time
VPS CPU Benchmarks: Copy a Test That Tracks Steal Time
Three signals decide whether a VPS CPU is any good: the single-core score, the multi-core score, and how the CPU behaves under sustained load, including steal time. Single-core predicts interactive and latency-sensitive work, multi-core predicts parallel throughput such as builds and batch jobs, and sustained-load results predict anything that keeps the CPU busy for hours.
TL;DR:
- Pair a Geekbench 6 snapshot with a sustained sysbench or stress run lasting five to fifteen minutes; burst scores can hide throttling and contention.
- Repeat tests at different times of day, record the CPU model, vCPU count, virtualization type, and benchmark version, then report medians and 95th percentiles.
- Compare plans only when the benchmark family, version, thread count, operating system, and virtualization type match; keep Geekbench and sysbench in separate rankings.
- Run fio and iPerf3 alongside a CPU job to expose storage bottlenecks and network slowdowns that CPU scores alone cannot reveal.
- Sample steal time every second during sustained load, but treat it as a contention clue rather than a pass or fail threshold.
Table of Contents
- 1. What do Geekbench, sysbench, and stress tests actually measure?
- 2. Why do sustained-load tests tell a different story than short runs?
- 3. Which metrics should you capture, and what do they tell you?
- 4. What is a repeatable VPS CPU test checklist you can copy?
- 5. How should you read a provider’s benchmark report?
- 6. How do AMD Ryzen VPS CPUs compare with other popular architectures?
- 7. How do frequency scaling and turbo boost change VPS CPU results?
- 8. Does KVM versus other virtualization change CPU benchmark outcomes?
- 9. How do NVMe storage and network latency interact with CPU benchmarks?
- 10. How we evaluate CPU performance at AceRDP
- FAQ
- Sources
1. What do Geekbench, sysbench, and stress tests actually measure?
Every tool answers a different question, so a score only means something when you know what workload sits behind it.
- Geekbench 6 reports separate single-core and multi-core scores. Its workloads cover compression, image processing, machine learning, and code compilation, and scores are calibrated against a baseline of 2,500, so a result twice as high means twice the performance on that scale. Its multi-core test uses a shared-task model, which is why results do not scale in a straight line with vCPU count.
- Sysbench runs a prime-number calculation test with explicit thread counts, run duration, warm-up time, and percentile reporting. It was built so that repeated runs can be compared fairly.
- Stress tools, fio, and iPerf3 add context a short synthetic run misses. A stress job keeps every vCPU busy for minutes, fio shows what storage does while the CPU is loaded, and iPerf3 shows whether network throughput holds up at the same time.
Geekbench gives you a quick, standardized snapshot. Sysbench gives you control over the test conditions. Stress tools show what happens when the party goes on past the first minute. You need all three roles covered to judge a plan honestly.
2. Why do sustained-load tests tell a different story than short runs?
A short benchmark can look great on a VPS that struggles under sustained load. Geekbench 6 deliberately inserts a 5-second gap between workloads in versions 6.1 and later to limit thermal bias. That design is sensible for a standardized score, but it also means a quick run may never reveal throttling or scheduling interference.
To see steady-state behavior, pair the short run with a longer one:
- Run a longer sysbench or stress job and watch throughput over time, not just the final average.
- Look for a slow decline in events per second, which points to thermal limits or frequency changes.
- Repeat the test at different times of day and plot the results. Sudden dips often mean a neighbor on the same host started a heavy job.
- Compare throughput at the start and end of the test. A healthy plan stays close to flat.
Pro Tip: Treat a flat line over a sustained test as more valuable than a high initial peak.
3. Which metrics should you capture, and what do they tell you?
Collect a small set of numbers every time, and keep them in the same format so runs can be compared.
- Single-core score: the best proxy for latency-sensitive, single-threaded tasks such as a database query path or a remote desktop session.
- Multi-core score: aggregate throughput for parallel work such as compilation or compression. Do not expect it to double when you double the vCPUs.
- Steal time: the guest-visible sign of CPU contention. Take repeated samples and look at the pattern, not a single reading.
- Percentiles and variance: report the median and the 95th percentile, plus standard deviation or min and max, so readers can see how stable the result is.
Steal time deserves special care. Linux documentation describes it as time a virtual CPU waits for physical CPU access because another workload is running.
Steal time is a contention signal, not a pass/fail grade: the kernel’s own steal-monitor proposal uses 2% and 5% as thresholds for its scheduling response, and those are implementation parameters, not a universal buying rule. Use it to ask better questions about a plan, not to settle the matter alone.
4. What is a repeatable VPS CPU test checklist you can copy?
Follow these steps in order, on a freshly booted instance, with nothing else running.
- Run a short Geekbench pass and save the single-core and multi-core scores, noting the Geekbench version.
- Run sysbench with one thread to measure per-core speed:
sysbench cpu --threads=1 --time=60 --warmup-time=5 --percentile=95 run - Run it again with threads set to your planned vCPU count:
sysbench cpu --threads=N --time=60 --warmup-time=5 --percentile=95 run - Start a long job of at least five to fifteen minutes, using a stress tool or sysbench with
--time=900, and sample steal time every second withvmstat 1ortop. - Repeat the whole sequence at different times of day, and keep the raw output files.
- Record the metadata listed below, then summarize with median, mean, 95th percentile, and run-to-run standard deviation, including sample timestamps.
For the log, write down the exact CPU model if the guest exposes it, the vCPU count, the virtualization type, benchmark versions, test duration, timezone and time of day, OS and kernel version, and number of repeats. Without that information, scores can be measuring different workloads or allocation policies.
Pro Tip: Save the raw output of every run. A summary without raw files cannot be audited later.
5. How should you read a provider’s benchmark report?
Most mistakes come from reading a report too generously. A few rules keep you honest:
- Don’t mix benchmark families in one ranking. Geekbench and sysbench use different workload designs and units, so their numbers cannot be merged.
- Do check for metadata gaps first. A score with no CPU model, vCPU count, virtualization detail, or test version is hard to trust.
- Do prefer sustained-run results when your workload runs continuously, and use steal-time patterns to flag noisy neighbors.
- Don’t accept a single high peak as proof of consistency. Ask for repeats and the spread between them.
- Do compare like with like: shared versus dedicated, same OS, same thread count.
6. How do AMD Ryzen VPS CPUs compare with other popular architectures?
Ryzen desktop-class cores typically combine high clock speeds with strong per-core throughput, which is why they tend to do well on single-core and lightly threaded tests. Server-class parts from other families are often built for density, with more cores at lower clocks and large caches, which can favor heavily parallel workloads. Neither design wins every test, and the right answer depends on what you run.
The practical way to compare is to hold everything else constant. Run the same Geekbench version, the same sysbench parameters, and the same duration on both architectures, and compare single-core and multi-core scores separately. A chip that wins single-core may lose a many-threaded batch job, and the reverse is just as common.
Do not compare Geekbench scores from one architecture against sysbench numbers from another. Keep each benchmark family in its own column and look for agreement between them. When both families point the same direction, the conclusion is much stronger.
We cover this in more depth in our Ryzen vs. Intel for VPS guide, including what to test for trading and dense-hosting workloads. Whatever architecture you choose, remember that the CPU model is only the starting point. Allocation policy, host load, and virtualization settings decide how much of that silicon you actually get.
7. How do frequency scaling and turbo boost change VPS CPU results?
Modern CPUs raise and lower their clock speed constantly. Turbo boost lets a core run above its base frequency when power and thermal limits allow, which can make a short single-core test look excellent. Frequency scaling then pulls clocks down when many cores are busy or the chip heats up.
That behavior explains why a quick run and a long run can disagree. A burst benchmark may capture the boosted state, while a sustained test captures the settled state your real workload will live in. For a VPS, the guest usually cannot see or control host frequency settings, so measuring over time is the only reliable way to know what you get.
Practical steps:
- Watch throughput across the full long run. A step down after the first minute suggests boost ending or power limits kicking in.
- Run the single-thread test, then the all-thread test, and compare. A large drop in per-thread speed under full load is normal, but a very large one deserves a question to the provider.
- Check the clock speed reported inside the guest, for example in
lscpuor/proc/cpuinfo, but treat it as a hint. Virtualized guests may report a nominal value rather than the live one. - Test at more than one time of day so a lightly loaded host does not flatter the numbers.
Boost is a feature, not a trick. It simply means your benchmark must be long enough to reach the clock speed your workload will see most of the time.
8. Does KVM versus other virtualization change CPU benchmark outcomes?
Virtualization adds a layer between your code and the hardware, and how thin that layer is affects results. KVM uses hardware virtualization extensions built into the CPU, so most instructions run directly on the processor with little overhead. Pure CPU-bound tests like prime calculation or compression usually show only a small gap from bare metal on a well-configured KVM guest.
Other approaches behave differently. Container-based virtualization shares the host kernel and can show very low overhead on CPU tests, but it also means resource limits and scheduling are controlled by the host in ways the guest cannot always see. Older or software-assisted methods can add more overhead, especially on workloads that make many system calls.
What matters for your benchmark:
- Always record the virtualization type in your log, since the same CPU can give different results under different setups.
- Check how vCPUs map to physical resources. A vCPU can be a full core or a hyperthread, which changes multi-core scaling. Our guide on vCPU versus CPU cores explains why a cautious baseline is a sensible starting point.
- Look at steal time. It is the clearest guest-side evidence of how the hypervisor is sharing the physical CPU.
Compare plans on the same virtualization type whenever you can. Otherwise a difference in scores may come from the platform, not the processor.
9. How do NVMe storage and network latency interact with CPU benchmarks?
A CPU benchmark measures the processor, but your real workload also waits on disk and network. A fast CPU paired with slow storage will still feel slow on a database, a build with many small files, or a remote desktop session that loads large profiles.
NVMe storage reduces that waiting. Run fio while a CPU job is active to see whether disk throughput and latency hold steady under load. If storage numbers collapse the moment all vCPUs are busy, the plan has a shared-resource bottleneck that a pure CPU score would hide.
Network latency matters in a different way. Interactive work, such as remote desktops or trading tools, depends on round-trip time and jitter as much as on clock speed. Run iPerf3 alongside your CPU test to see whether throughput and latency stay steady while the processor is working hard. For deeper network diagnostics such as jitter, packet loss, and queueing delay, this bufferbloat test guide covers methods you can run alongside your CPU checks.
A balanced evaluation reads like this:
- CPU score for compute speed.
- Steal time and run-to-run variance for contention.
- fio results for storage under load.
- iPerf3 and latency checks for the network path.
When all four look steady, the plan will behave the way the headline benchmark suggests.
10. How we evaluate CPU performance at AceRDP
We prioritize four things: single-core latency, sustained multi-core throughput, NVMe I/O context, and low-latency networking. A high peak means little to us unless it holds up across repeats and over time, and we encourage you to run the checklist above on any plan, ours included. If you want to compare notes, we are glad to discuss our approach. For deeper reading, see our write-up on high-CPU VPS testing and our server optimization guides.
— AceRDP
FAQ
What is a good VPS CPU benchmark score?
There is no universal “good” number, because scores depend on the tool, version, and workload. Compare plans using the same Geekbench version and the same sysbench parameters, and judge single-core and multi-core scores separately. Geekbench 6 is calibrated to a baseline of 2,500, and a higher score means proportionally higher relative performance.
How long should a VPS CPU test run?
Use a short run for a quick snapshot, then a sustained run of at least five to fifteen minutes to see steady-state behavior. Short runs can miss throttling and scheduling interference. Repeat the test at different times of day so you can see how much results vary.
What is steal time and why does it matter?
Steal time is the share of time your virtual CPU waited for physical CPU access because another workload was running. It is a guest-visible contention signal, best read as a pattern across repeated samples. Persistent high values during your tests suggest a noisy neighbor.
Can I compare Geekbench and sysbench scores directly?
No. The two tools use different workload designs and units, so their numbers cannot be merged into one ranking. Keep each benchmark family separate and look for agreement between them.
