Benchmarking a VPS Before You Commit: CPU Steal, Disk IOPS and Network Jitter in 20 Minutes

Synthetic benchmark scores are marketing. What matters for a production VPS is how the provider behaves under the contention patterns you will actually create: sustained CPU load, small random I/O, and latency-sensitive network round trips. This article gives you a repeatable twenty-minute test suite that measures the numbers that predict real performance, and explains how to interpret them without fooling yourself.

Use a throwaway instance. If the host passes, sign up. If you want a shortlist to test against, start from the VPS options on our main site, which summarises the provider characteristics worth benchmarking in the first place.

Measure CPU Steal First — It Explains Most Mysteries

On a VPS you share physical cores. Steal time is the fraction of time your vCPU was runnable but the hypervisor gave the physical core to someone else. High steal explains seemingly random latency spikes that no amount of application tuning fixes.

grep ^cpu /proc/stat; vmstat 2 30 | awk '{print $16}' | tail -n +3 | sort -n | tail -5
mpstat -P ALL 1 10 | grep -E "Average|%steal"

Run these while generating load with sysbench cpu --threads=$(nproc) run. Steal above roughly five percent on a dedicated-vCPU plan is a red flag; a few percent as a brief spike under neighbour pressure is normal. Record the maximum, not the average, because latency-sensitive workloads feel the peaks.

Also capture per-vCPU variance. If one vCPU consistently shows much higher steal than the others, you may be pinned to a busy physical core and no amount of tuning will help. This is a provider-level problem, so it belongs in your go or no-go decision.

Disk Benchmarks That Reflect Real Workloads

dd with a big block size measures sequential throughput, which almost nothing uses. Databases and mail queues do small random reads and writes with a queue depth above one. Use fio with a mixed read/write profile and watch the latency percentiles.

fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --bs=4k \
  --iodepth=16 --numjobs=4 --size=1G --runtime=60 --time_based \
  --group_reporting

Capture iops, bw, and the clat percentiles block. The p99 read latency is the number that matters for interactive services. Sequential throughput with --bs=1M --rw=read tells you about backup and restore times, which is a different question and deserves its own figure.

• Random 4k read/write at iodepth 16: interactive database and web workload
• Sequential 1M read: backup restore and large file transfer
• Low iodepth (1) 4k read: single-threaded application feel
• Compare the same test at the start and end of a month-long trial to spot neighbour drift

Network Jitter Beats Raw Throughput for Most Services

A 10 Gbit link with 40 ms of jitter produces worse user experience than a 1 Gbit link with 1 ms jitter. Measure round-trip latency distribution to several destinations, not one speed test to one server.

for i in $(seq 1 100); do ping -c1 -W1 1.1.1.1 | tail -1 | awk '{print $4}' | cut -d/ -f2; done | sort -n | awk '{a[NR]=$1} END{print "min",a[1],"p50",a[int(NR*0.5)],"p95",a[int(NR*0.95)],"max",a[NR]}'
mtr -rwzc 50 1.1.1.1

Add a throughput reading with iperf3 against a public server, and a TCP-level check with ss -ti to see retransmits and the congestion window your kernel settles on. Persistent retransmits on a healthy path point at a congested uplink or a misconfigured MTU.

Memory Bandwidth and Working-Set Behaviour

VPS memory is cheap until it is not. Measure effective memory bandwidth with sysbench memory run and watch how quickly the working set leaves cache. A provider that throttles memory bandwidth under contention will show it here.

sysbench memory --memory-block-size=1M --memory-total-size=10G run
dd if=/dev/zero of=/dev/shm/test bs=1M count=4096 oflag=direct 2>&1 | tail -1

/dev/shm lives in RAM, so the second command isolates memory and CPU path speed from disk entirely. If the shared-memory write is slow, you have a CPU or memory-controller bottleneck rather than a storage one.

Put the Host Under Your Own Contention

Ratings are meaningless without load. Run three things at once: sysbench cpu --threads=$(nproc), the fio profile above, and a ping loop. Now you are testing how the host arbitrates, which is exactly what happens in production during a traffic spike.

• Simultaneous CPU saturation plus random I/O exposes scheduler and storage contention
• Run the ping loop throughout and record p99 latency under load, not at idle
• Take mpstat and iostat -x 1 samples during the test as evidence
• Compare idle versus loaded p99, that delta is your true headroom number

Interpreting the Results Without Fooling Yourself

Three rules keep you honest. First, run every test at least twice at different times of day; a single run measures the neighbour, not the host. Second, compare like instance types — burstable vCPU plans will always look worse under sustained load by design. Third, decide what your workload is sensitive to before you look at the numbers, so you do not rationalise a bad result because the throughput figure was pretty. A cache-heavy web server cares about p99 read latency; a backup host cares about sequential write throughput; a game server cares about jitter. Rank the tests accordingly and weight your decision.

Watch for throttling signatures too. If CPU frequency drops and steal rises together as the test runs, the provider is enforcing a CPU credit or thermal policy. Check cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq before and during load, and cross-check with the steal figures. A burstable instance that performs beautifully for two minutes and then collapses is not a bargain for a sustained workload, however good the first screenshot looks.

Keep a written record of every trial instance with the raw output. When a provider quietly changes hardware, your historical data is the only way to prove the regression. This is the same measurement discipline behind our VPS performance tuning guides — instrument, benchmark, document, compare.

A Twenty-Minute Checklist

The full suite fits in twenty minutes: five for steal monitoring under load, seven for the fio random and sequential runs, three for the latency distribution, three for memory bandwidth, and two for writing the results down. Do it on a trial instance before you commit a year of budget, and keep the output as your baseline.

If the host shows low and steady steal, consistent p99 disk latency, and tight network jitter, you have found a keeper. If any one of those is poor, no amount of kernel tuning on your side will fix it — change providers, then tune. Benchmarking is a purchasing decision tool first and a tuning tool second.