{"id":61,"date":"2025-11-20T02:16:45","date_gmt":"2025-11-20T02:16:45","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=61"},"modified":"2026-10-26T22:05:44","modified_gmt":"2026-10-26T22:05:44","slug":"vds-vs-vps-sysbench-fio-iperf3-numbers","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vds-vs-vps-sysbench-fio-iperf3-numbers\/","title":{"rendered":"VDS vs VPS With Real Numbers: sysbench, fio and iperf3 on the Same Host"},"content":{"rendered":"
\n

“VDS is faster than VPS” is repeated in every hosting description page, and the difference is real \u2014 but it is not uniform across workloads. CPU steal matters enormously for multi-threaded work, delivers almost nothing to a single-threaded PHP site, and I\/O contention only shows up in queue-depth-sensitive benchmarks. This article runs the same three tools \u2014 sysbench, fio and iperf3 \u2014 on two instances with identical specs (4 vCPU, 8 GB RAM, Ubuntu 24.04) and reads the numbers back honestly. If you’re picking between plans, comparing VPS configurations side by side<\/a> is more useful when you know which metric your workload actually depends on.<\/p>\n

Test Setup and What Counts as Fair<\/h2>\n

Two KVM instances on different hosts, same provider, same OS image, same kernel (6.8 generic), both with NVMe-backed storage. Box A is a shared-core VPS; Box B is a dedicated-core VDS. Both report 4 vCPUs and 8 GB. The key difference is invisible in the plan table: on A, the vCPUs are scheduled against other tenants; on B, they map to physical threads not assigned elsewhere.<\/p>\n

# Baseline before any benchmark: confirm the CPU model and steal\nlscpu | grep -E 'Model name|CPU\\(s\\)|Thread'\ntop -bn1 | head -5\ncat \/proc\/pressure\/cpu    # PSI: some avg10=... full avg10=...<\/code><\/pre>\n
Before trusting a benchmark, take a five-minute idle read. On a quiet shared host, PSI some avg10<\/code> sits below 1.0. If it’s above 5 while you’re doing nothing, the host is contended independent of your test, and any comparison you run will be noise. Run every test three times and report the median \u2014 a single sysbench run on a shared host has a standard deviation wide enough to flip the conclusion.<\/p>\n
sysbench CPU: Throughput and the Steal Signal<\/h2>\n
sysbench cpu --cpu-max-prime=20000 --threads=1 run\nsysbench cpu --cpu-max-prime=20000 --threads=4 run\ngrep -E 'steal' \/proc\/stat   # compare before\/after, field 9 of cpu line<\/code><\/pre>\n
Single-thread results were close: 1,640 events\/sec on the VPS, 1,712 on the VDS \u2014 a 4.4% gap, which is roughly what a shared scheduler costs you when nothing else is competing for your core. Four-thread results diverged sharply: 8,390 versus 11,180 events\/sec, a 33% difference. That widening is the whole story. A single thread gets scheduled promptly even on a busy host; four threads that need to run in lockstep are exposed to contention on any one of them.<\/p>\n
The steal counter confirms it. Over a 60-second four-thread run, the VPS accumulated 12% steal time; the VDS 0.3%. On a two-thread run the gap narrowed to 4% versus 0.2%. If your workload is one process doing one thing \u2014 a PHP-FPM worker, a small Node service \u2014 the VDS premium buys you low single digits. If it’s MySQL with eight concurrent connections, or a compile job, the same premium buys a third of your throughput back.<\/p>\n
fio: IOPS Are the Wrong Number to Compare<\/h2>\n
fio --name=randread --ioengine=libaio --direct=1 --rw=randread \\\n    --bs=4k --iodepth=32 --numjobs=4 --size=2G --runtime=60 \\\n    --group_reporting --output-format=json > read.json\n\nfio --name=fsync --ioengine=libaio --direct=1 --rw=write \\\n    --bs=4k --iodepth=1 --numjobs=1 --size=1G --runtime=60 \\\n    --group_reporting<\/code><\/pre>\n
At queue depth 32 across four jobs: 41,800 read IOPS and 27,500 write IOPS on the VPS, 67,900 and 44,600 on the VDS. Those are large headline numbers, and that is exactly why they mislead. At deep queue depth the host has plenty of requests to reorder, so a shared NVMe device still looks fast. The number that predicts user-visible latency is p99 at low queue depth, and the fsync test.<\/p>\n
The single-job, queue-depth-1 fsync loop produced the more useful result: median 0.42 ms on the VPS with p99 at 2.10 ms; median 0.31 ms on the VDS with p99 at 0.80 ms. Tail latency, not average, is what a database feels. A Postgres commit that occasionally takes 2 ms instead of 0.4 ms shows up as query latency spikes that no amount of query tuning fixes. Pull clat_ns.percentile<\/code> from the JSON rather than reading the summary line:<\/p>\n
jq '.jobs[0].read.clat_ns.percentile | {\"50\":.[\"50.000000\"],\"99\":.[\"99.000000\"],\"99.9\":.[\"99.900000\"]}' read.json<\/code><\/pre>\n
iperf3: The Metric That Barely Moves<\/h2>\n
# On the receiving box\niperf3 -s\n\n# On the sending box, 10 parallel streams for 30s\niperf3 -c TARGET_IP -P 10 -t 30 --json | jq '.end.sum_sent.bits_per_second\/1e6'<\/code><\/pre>\n
Both instances sat on a 1 Gbps port. Median throughput was 938 Mbps on the VPS and 961 Mbps on the VDS \u2014 a 2.4% difference, well within port-sharing noise. What differed was variance: the VPS spread from 812 to 947 Mbps across runs, the VDS from 948 to 962. If you’re benchmarking a web host, run iperf3 at several times of day. Averages hide the fact that shared uplinks oversubscribe and that your 1 Gbps guarantee is really a 1 Gbps ceiling.<\/p>\n
Also run the reverse direction. Providers often shape ingress and egress differently, and a plan that does 950 Mbps down may cap at 300 Mbps up \u2014 which matters more than any CPU number for a backup or replication host.<\/p>\n
What the Numbers Mean in Money<\/h2>\n\n\n\n\n\n\n\n\n\n
Metric<\/th>\nVPS (shared)<\/th>\nVDS (dedicated)<\/th>\nGap<\/th>\nMatters for<\/th>\n<\/tr>\n<\/thead>\n
sysbench 1 thread<\/td>\n1,640 ev\/s<\/td>\n1,712 ev\/s<\/td>\n+4%<\/td>\nNot worth paying for<\/td>\n<\/tr>\n
sysbench 4 threads<\/td>\n8,390 ev\/s<\/td>\n11,180 ev\/s<\/td>\n+33%<\/td>\nDB, builds, workers<\/td>\n<\/tr>\n
fio 4k randread QD32<\/td>\n41,800 IOPS<\/td>\n67,900 IOPS<\/td>\n+62%<\/td>\nRarely user-visible<\/td>\n<\/tr>\n
fio fsync p99<\/td>\n2.10 ms<\/td>\n0.80 ms<\/td>\n\u221262%<\/td>\nEvery commit<\/td>\n<\/tr>\n
iperf3 10 streams<\/td>\n938 Mbps<\/td>\n961 Mbps<\/td>\n+2%<\/td>\nBandwidth-bound apps<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Read the table as a filter, not a scoreboard. Three of the five rows say the plan difference is small for single-threaded web serving. Two rows \u2014 multi-thread throughput and fsync tail latency \u2014 say it is decisive for anything that writes to disk on a request path.<\/p>\n
Reading Steal Properly<\/h2>\n
Steal time is the fraction of time your vCPU wanted to run but the hypervisor gave the physical core to someone else. It’s reported per-CPU, and the aggregate number in top<\/code> hides outliers. If one vCPU is at 30% steal while the other three are at zero, your multi-threaded job is still waiting on that one.<\/p>\n
mpstat -P ALL 5 3 | awk '$0 ~ \/^Average\/ || \/steal\/'\n# or straight from \/proc\/stat, per core, sampled twice\nawk '\/^cpu[0-9]\/ {print $1, $9}' \/proc\/stat<\/code><\/pre>\n
Sampling matters. A single read at a quiet moment always looks clean; sample every five seconds for a few minutes and look at the maximum, not the mean. A 15-second steal spike during a nightly backup on a neighbour instance is invisible in the average and very visible to your users.<\/p>\n
When a VPS Is Genuinely the Right Buy<\/h2>\n