How to Benchmark a VPS: Real Tests for CPU, Disk, Network & Latency

Every VPS provider on earth claims "blazing-fast NVMe" and "enterprise-grade CPUs". Some of it's real. Most of it isn't. Here are the four tests I run on every VPS within the first hour, with reference numbers so you know what a good result actually looks like.

Everything here works on a fresh Ubuntu 22.04+ install.

Tool 1 — CPU with sysbench

sysbench measures raw integer performance — the kind of work your app server spends most of its time on. Install and run:

sudo apt update && sudo apt install -y sysbench
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run

Look at "events per second" at the bottom. Rough tiers for a single vCPU:

Events/sec (1 thread)	What it means
> 5000	Recent EPYC / Xeon Gold — excellent
3000–5000	Typical modern VPS — good
1500–3000	Older Xeon E5 / overcrowded host
< 1500	Ancient or heavily oversold — avoid

Multiply by number of vCPU for the theoretical ceiling, though in practice hypervisor contention drags it below that under load.

Tool 2 — Disk with fio

fio is the only disk benchmark worth running — dd is misleading on every modern filesystem. Random 4K reads and writes are what real databases and web apps actually do:

sudo apt install -y fio

# 4K random read (IOPS-focused)
fio --name=randread --ioengine=libaio --direct=1 --rw=randread \
    --bs=4k --size=1G --numjobs=4 --runtime=30 --group_reporting

# 4K random write (IOPS-focused)
fio --name=randwrite --ioengine=libaio --direct=1 --rw=randwrite \
    --bs=4k --size=1G --numjobs=4 --runtime=30 --group_reporting

# 1M sequential read (throughput-focused)
fio --name=seqread --ioengine=libaio --direct=1 --rw=read \
    --bs=1M --size=2G --numjobs=1 --runtime=30 --group_reporting

Reference numbers for "NVMe-backed VPS":

Metric	Minimum good	Excellent
4K random read	20k IOPS	> 80k IOPS
4K random write	10k IOPS	> 40k IOPS
1M sequential read	500 MB/s	> 2 GB/s

Anything under 5k IOPS on 4K reads is SATA SSD or worse — check the spec sheet matches.

Tool 3 — Network with iperf3

Bandwidth claims are the easiest to fake. Test against a well-known public server:

sudo apt install -y iperf3

# Pick a nearby public iperf3 server from
# https://iperf.fr/iperf-servers.php — then:
iperf3 -c speedtest.serverius.net -p 5002 -P 8 -t 20
# -P 8 = 8 parallel streams, which saturates the link

Look at the receiver throughput. A "2 Gbps" VPS should hit at least 1.5 Gbps sustained to a nearby public server. Hitting 300 Mbps means the provider is throttling or badly peered.

Also test outbound to your actual users' network. European VPS performs great to European servers — it's useless if your users are in Brazil.

Tool 4 — Latency with mtr

Bandwidth without low latency is useless for web apps. mtr shows every hop between your VPS and a target:

sudo apt install -y mtr-tiny
mtr -rwc 100 8.8.8.8

Look at the final row:

• Loss% = 0 across all hops. Any packet loss on intermediate hops is fine, but loss on the final hop is a deal-breaker.
• Avg latency should match geography: 1-5ms within the same datacenter, 10-30ms within the same continent, 100-200ms across oceans.

Run mtr to 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), and one of your own users' ISPs for a rounded picture.

Bonus — YABS all-in-one script

If you want a single copy-pasteable one-liner, the community-maintained Yet Another Bench Script runs sysbench, fio, and speedtest against multiple regions in one go:

curl -sL yabs.sh | bash

It takes 10-15 minutes and produces a neat markdown block you can paste into reviews or tickets.

What to do with the numbers

• Benchmark on day 1, then again at day 30. If performance dropped >20%, the host is oversold — file a ticket or move.
• Run the same benchmark on two providers before committing long-term. Don't trust marketing specs; trust fio output.
• Keep a log. A text file in /root/benchmarks.log with dated sysbench output has saved me from a lot of "is it slower?" arguments.

Two hours of benchmarking up front saves weeks of "why is production slow" debugging later. Try our plans — all on KVM + NVMe, built to pass every one of these tests.