How to Benchmark a VPS Properly: CPU, Memory, Disk IOPS, and Network in 20 Minutes

“4 vCPU / 8 GB RAM / NVMe” tells you the shape of a VPS but nothing about how fast it will actually run. Two hosts selling identical spec sheets can differ by 40% in real throughput because of hypervisor overhead, CPU steal from noisy neighbours, storage contention, and network path quality. The only way to know what you bought is to measure it.

This is a complete, repeatable benchmark suite you can run in about 20 minutes on a fresh VPS. Run it before you commit to a long contract, and again after deployment so you have a baseline to compare against when something “feels slow” later.

Before You Start

sudo apt update && sudo apt install -y sysbench fio iperf3 htop curl jq bc

Run benchmarks on an idle system, not while your application is building caches or running backups. And run each test at least twice — the second result is usually the honest one, once the caches and CPU have warmed up.

1. CPU: Throughput and Steal Time

sysbench measures raw compute in events per second. Prime numbers are the standard workload because they are deterministic and comparable across machines:

# Single-core
sysbench cpu --cpu-max-prime=20000 --threads=1 run




# All cores
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Compare the multi-core score to the single-core score multiplied by core count. If multicore scaling is poor, the provider may be over-committing physical cores.

Then check steal time — the percentage of CPU time your VM wanted but the hypervisor gave to someone else:

top -bn1 | head -5
# or
mpstat 1 5

Under 1% steal is healthy. Sustained 5–10% means noisy neighbours and explains erratic latency. Above 10%, open a support ticket with your measurements; that is not a configuration problem you can fix.

2. Memory: Bandwidth and Latency

Throughput per core tells you how much memory bandwidth the host actually exposes to your VM:

sysbench memory --memory-block-size=1M --memory-total-size=10G \
  --memory-oper=read --threads=$(nproc) run




sysbench memory --memory-block-size=1M --memory-total-size=10G \
  --memory-oper=write --threads=$(nproc) run

Watch the “MiB/sec” figure. A modern host should deliver tens of GB/s aggregate; anything far below that on a multi-core plan suggests memory channel throttling or a busy host.

3. Disk: IOPS, Latency, and Throttling

Disk is where VPS performance usually falls apart, because storage is the most heavily shared resource. fio gives you the real numbers — random reads, sequential writes, and mixed workloads:

# Random 4K read IOPS (typical database pattern)
fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread \
    --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=30 --group_reporting




# Sequential write throughput (backups, logs)
fio --name=seqwrite --ioengine=libaio --iodepth=16 --rw=write \
    --bs=1M --direct=1 --size=2G --runtime=30 --group_reporting



# Mixed 70/30 read/write (web application pattern)
fio --name=mixed --ioengine=libaio --iodepth=32 --rw=randrw --rwmixread=70 \
    --bs=4k --direct=1 --size=1G --runtime=30 --group_reporting

Read these fields in the output:

• iops — how many operations per second the volume sustains. A decent NVMe VPS should do 3,000–20,000+ random-read IOPS at 4K.
• clat p99 — 99th-percentile completion latency. Under 1 ms is good; spikes to 10 ms+ indicate a throttled or oversubscribed volume.
• iops consistency — if the second 30-second run drops far below the first, you hit an IOPS cap. Providers throttle burst credits; sustained performance is what your database actually gets.

Run the same fio test immediately after a fresh boot, then again after a few minutes of load. A big drop between the two is the signature of burst-credit throttling.

4. Network: Bandwidth and Latency

Network benchmarks need a peer. For a quick sanity check, use a nearby public endpoint, or spin up a second short-lived VPS and test against it for clean, uncontended numbers:

# On the test peer
iperf3 -s




# On your VPS — upstream throughput
iperf3 -c PEER_IP -t 10 -P 4



# Reverse direction
iperf3 -c PEER_IP -t 10 -P 4 -R

Providers often quote asymmetric bandwidth, so test both directions. Then trace the path to your users:

mtr -rw -c 20 1.1.1.1
mtr -rw -c 20 YOUR_MAIN_USER_ASN_TARGET

Look for loss on any hop after the first two (which are your VPS and the provider’s edge). Consistent packet loss on a mid-path hop points to peering problems that will hurt every TCP connection your users make.

5. Interpret the Results in Context

Raw numbers mean nothing without a workload. Match the test to what you run:

Workload	Metric that matters most
Web server (Nginx + PHP)	Multi-core CPU score, 4K random-read IOPS
MySQL / PostgreSQL	Random-read IOPS, p99 disk latency, memory bandwidth
Redis / in-memory cache	Memory bandwidth, single-core CPU
Static file / media serving	Network throughput, sequential read IOPS
Build server / CI agent	Multi-core CPU, sequential write throughput

A VPS that scores brilliantly on CPU but shows 15 ms p99 disk latency will make a terrible database server. Benchmark the dimension your application is actually bottlenecked on.

Make Benchmarking Part of Your Buying Process

Run this suite on a trial instance before you pay for a year, and keep the output in your runbook. When performance degrades months later, you have a documented baseline that makes the provider conversation concrete instead of anecdotal.

If you want a shortlist that already has verified baseline numbers attached, start with our VPS comparison table, which records real test results rather than spec-sheet claims. For the interpretation side — how to read load average, iowait, and steal together — see the notes in the FAQ, and our deeper write-up on reading VPS benchmark results.