{"id":770,"date":"2026-08-02T02:35:28","date_gmt":"2026-08-02T02:35:28","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=770"},"modified":"2026-10-07T22:03:11","modified_gmt":"2026-10-07T22:03:11","slug":"how-to-benchmark-your-vps-cpu-disk-and-network-testing-explained","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/how-to-benchmark-your-vps-cpu-disk-and-network-testing-explained\/","title":{"rendered":"A Repeatable VPS Benchmark Method: Isolating CPU Steal, Disk p99 and Network Jitter"},"content":{"rendered":"
\n\n\n

Most VPS benchmarks fail because they compare a single run against a screenshot from a review site, on different hardware, at a different time of day. A useful benchmark instead isolates one variable at a time and produces a number you can re-measure later. This method separates three signals that are routinely conflated: CPU steal, disk tail latency, and network jitter.<\/p>\n\n\n\n

Establish a Baseline Under Idle Load<\/h2>\n\n\n\n

Run every test twice: once on an idle system, once under representative load. The gap between the two reveals contention, not capability. Record the following before you generate any load:<\/p>\n\n\n\n

nproc\ncat \/proc\/loadavg\nvmstat 1 5\nuptime\ncat \/sys\/fs\/cgroup\/cpu.stat 2>\/dev\/null<\/code><\/pre>\n\n\n\n
From vmstat<\/code>, the st<\/code> column is CPU steal time \u2014 the percentage of cycles the hypervisor took away from your vCPU. Any sustained st<\/code> above 5% during an idle baseline means the physical host is oversubscribed and your measurements will be noisy.<\/p>\n\n\n\n
CPU: Distinguish Steal from Throttling<\/h2>\n\n\n\n
Use sysbench to measure raw throughput, but interpret it against steal:<\/p>\n\n\n\n
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run\nsysbench cpu --cpu-max-prime=20000 run<\/code><\/pre>\n\n\n\n
The single-threaded run tests per-core performance; the multi-threaded run tests how well the instance scales. If events-per-second scales sublinearly while st<\/code> climbs, the bottleneck is host contention, not your workload. Cross-check with perf stat -e cpu-clock,task-clock<\/code> on a fixed loop to catch frequency scaling that sysbench hides.<\/p>\n\n\n\n
Disk: Measure Tail Latency, Not Averages<\/h2>\n\n\n\n
Average IOPS is the least useful disk number on a shared NVMe host. The metric that determines user experience is the p99 and p99.9 latency at a realistic queue depth. fio reports percentiles directly:<\/p>\n\n\n\n
fio --name=randread --ioengine=libaio --direct=1 \\\n  --rw=randread --bs=4k --iodepth=16 --numjobs=4 \\\n  --size=1G --runtime=60 --time_based \\\n  --lat_percentiles=1 --percentile_list=50:95:99:99.9 \\\n  --group_reporting<\/code><\/pre>\n\n\n\n
A healthy shared-NVMe instance at 4K random read, iodepth 16, shows p99 latencies in the low hundreds of microseconds. When p99 is 5\u201310x the p50, you are seeing queueing caused by a noisy neighbor rather than device speed. That distinction matters: a faster plan will not fix contention, but a different provider will.<\/p>\n\n\n\n
Metric<\/th>Good sign<\/th>Red flag<\/th><\/tr><\/thead>
p99 (4K randread)<\/td>< 500 \u00b5s<\/td>> 2 ms<\/td><\/tr>
p99\/p50 ratio<\/td>< 3x<\/td>> 5x<\/td><\/tr>
IOPS vs plan spec<\/td>within 15%<\/td>< 60% of spec<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Network: Measure Jitter, Not Just Throughput<\/h2>\n\n\n\n
A single iperf3 run gives you peak bandwidth, which tells you almost nothing about application performance. Run several short transfers and record the spread, then probe latency stability:<\/p>\n\n\n\n
# On the peer: iperf3 -s\nfor i in 1 2 3 4 5; do\n  iperf3 -c PEER --time 5 -P 4 | grep -E \"SUM.*sender\"\ndone\nping -c 200 PEER | tail -3\nmtr --report --report-cycles 100 PEER<\/code><\/pre>\n\n\n\n
Watch the standard deviation, not the peak. A link that delivers 900 Mbit\/s at peak but varies by 40% run-to-run has a bufferbloat or virtual-switch contention problem. mtr<\/code>‘s loss column distinguishes loss at your gateway from loss further upstream \u2014 only the former is your provider’s responsibility.<\/p>\n\n\n\n
Interpreting the Numbers in Context<\/h2>\n\n\n\n
No benchmark result exists in isolation. A single-threaded sysbench score of 4,000 events per second means nothing until you know the reference class \u2014 a modern shared-vCPU tier typically lands between 3,000 and 6,000, while a dedicated-core tier reaches two to three times that. Similarly, disk numbers must be read at the queue depth your workload actually generates; a web application rarely drives iodepth 32, so a benchmark at that depth can flatter an instance that disappoints in production.<\/p>\n\n\n\n
The most common mistake is measuring a burst and assuming it is steady state. Shared hosts often burst above their sustained allocation for a few seconds to make interactive tests look good. Run every test for at least 60 seconds with --time_based<\/code> and compare the first ten seconds against the last ten. A meaningful drop between them is throttling, and it will show up under real sustained load even if a short test hides it.<\/p>\n\n\n\n
Repeatability Is the Point<\/h2>\n\n\n\n
Store your commands and results in a file so the next run is comparable. A benchmark you cannot repeat is an anecdote. When results degrade weeks later, re-running the identical commands turns “the server feels slow” into “p99 disk latency rose from 300 \u00b5s to 2.1 ms.”<\/p>\n\n\n\n