How to read VPS benchmark results (sysbench, fio, iperf3)
Why VPS benchmarks matter (and why they can mislead)
When you shop for a VPS, you’ll often see benchmark screenshots or tables: “Sysbench score,” “fio 4k IOPS,” “iperf3 10 Gbps.” These can be useful signals about CPU speed, disk performance, and network throughput—but only if you know what each test actually measures and how to compare results fairly.
Benchmarks are synthetic: they stress one subsystem at a time under controlled patterns. Real workloads (web apps, databases, game servers, CI runners) mix CPU, storage, memory, and network in ways synthetic tests don’t fully replicate. Your goal is to interpret results as clues, not promises.
This guide covers three common tools:
- Sysbench: CPU and memory microbenchmarks (and sometimes database tests)
- fio: disk I/O performance under different access patterns
- iperf3: network bandwidth and stability between two endpoints
Sysbench: CPU and memory
What Sysbench is good for
Sysbench is a small, widely used benchmark tool. For VPS comparisons, you’ll mainly see:
- CPU test (single-thread or multi-thread): measures raw compute
- Memory test: measures memory throughput (copy/read/write speed)
Common Sysbench CPU output and how to read it
A typical CPU test looks like:
```bash sysbench cpu --cpu-max-prime=20000 --threads=1 run ```
You’ll usually see:
- events per second (or “events/s”): higher is better
- total time: lower is better
- latency (avg, 95th percentile, max): lower is better
#### Single-thread vs multi-thread
- Single-thread (`--threads=1`) reflects per-core performance and is often important for:
- Multi-thread (`--threads=N`) reflects how well the VPS scales across its allocated vCPUs.
What Sysbench memory numbers mean
Example:
```bash sysbench memory --memory-block-size=1M --memory-total-size=10G run ```
Outputs often include:
- MiB/s or GiB/s throughput: higher is better
- virtualization overhead can affect results
- NUMA layout and host contention can skew throughput
- some providers use different CPU generations; memory bandwidth scales with platform
---
fio: disk I/O (the most misunderstood results)
Why fio matters
Storage performance can make or break VPS experience. Disk affects:
- database latency (MySQL/Postgres)
- package installs, Docker image pulls
- boot times and updates
- logs and write-heavy apps
- queueing under load
The three core fio metrics
fio results typically include:
- IOPS (I/O operations per second): “how many reads/writes per second”
- Bandwidth / Throughput (MB/s or MiB/s): “how much data per second”
- Latency (avg, percentiles like 95th/99th): “how long each operation takes”
- Small-block random I/O → focus on IOPS and latency
- Large sequential I/O → focus on throughput
- Databases care a lot about 99th percentile latency, not just average
Understanding common workload patterns
#### 4k random read/write (IOPS-heavy)
Often shown as “4k randread” or “4k randrw”. Example command pattern:
```bash fio --name=randread --rw=randread --bs=4k --iodepth=32 --numjobs=1 --size=2G --time_based --runtime=60 --direct=1 ```
- bs=4k means 4 KiB blocks (database-like)
- rw=randread means random reads
- iodepth=32 means up to 32 requests in flight
- direct=1 attempts to bypass OS page cache (more realistic for storage testing)
- Very high IOPS with very high latency can still be bad for databases.
- A provider can tune for impressive IOPS at high queue depth, but your app might run at low depth (1–4).
Example:
```bash fio --name=seqread --rw=read --bs=1M --iodepth=16 --numjobs=1 --size=4G --time_based --runtime=60 --direct=1 ```
This measures large-file streaming. Great for backups, media, big downloads—but not necessarily predictive for database responsiveness.
The biggest fio “gotcha”: caching
If tests do not use direct I/O and/or the file size is too small, results may be mostly RAM cache, not disk.
Red flags:
- unbelievably high “disk” read speeds (many GB/s) on a budget VPS
- tests run with tiny `--size` (e.g., 256M) on machines with multiple GB RAM
- missing mention of `direct=1` (or equivalent)
- repeated runs that get faster and faster (warm cache)
Queue depth and numjobs: why two fio results aren’t comparable
- iodepth and numjobs change the pressure you put on storage.
- Higher queue depth can inflate throughput/IOPS by keeping the device busy, but can also inflate latency.
- `rw` pattern, `bs`, `iodepth`, `numjobs`
- runtime (e.g., 60s) and size (large enough to exceed cache, often several GB)
- direct I/O usage
iperf3: network bandwidth (and consistency)
What iperf3 measures
iperf3 measures TCP or UDP throughput between two endpoints:
- Bandwidth (Mbits/sec or Gbits/sec)
- Sometimes retransmits (TCP) indicating packet loss or congestion
- For UDP: jitter and packet loss
```bash
iperf3 -c
- `-P 4` runs 4 parallel streams (often closer to real usage and can better fill high-latency links)
- `-t 30` runs for 30 seconds
How to interpret iperf3 output
- Bandwidth: higher is better, but only meaningful relative to:
- Retransmits (TCP): lots of retransmits can mean packet loss or congestion. High bandwidth with high retransmits can translate into unstable real-world transfers.
Comparing providers with iperf3
To compare “provider A vs provider B,” test to the same target(s):
- one server in the same region
- one server in a different region you care about
- optionally, a major cloud region (to gauge peering quality)
---
Turning benchmark numbers into real decisions
Map benchmarks to your workload
- Web hosting (WordPress, small sites): CPU single-thread and disk latency matter more than huge sequential throughput.
- Databases: fio 4k random read/write, especially 99th percentile latency, is crucial.
- CI/build servers: Sysbench multi-thread + decent disk throughput.
- Backup/storage node: fio sequential throughput + network throughput.
- Game servers: Sysbench single-thread + stable network latency (iperf3 doesn’t measure latency directly).
Compare providers like a professional
1. Standardize the tests - Same sysbench settings (prime limit, threads) - Same fio job (pattern, block size, iodepth, numjobs, direct I/O, runtime) - Same iperf3 targets, parallelism, duration
2. Look for consistency - Run 3 times and compare spread. - Big variance suggests noisy neighbors, bursting, or throttling.
3. Watch percentiles, not just averages - For fio, a low average latency with terrible 99th percentile is a bad sign for databases.
4. Check the environment - Providers may allocate “vCPUs” that are heavily shared. - Storage might be local NVMe, network-attached SSD, or even HDD-backed in worst cases.
---
Red flags in benchmark marketing
Cherry-picked fio tests
If you only see one metric like “1M sequential read: 3,500 MB/s,” that might be the best-looking scenario. Ask:- what about 4k random?
- what about write performance?
- what about latency percentiles?
Suspiciously perfect network numbers
“10 Gbps” is often a port speed, not guaranteed throughput. Real throughput depends on:- CPU limits (encryption, TCP stack)
- shaping policies
- oversubscription and contention
- routing
Sysbench without context
Sysbench CPU results are meaningless without:- threads used
- prime limit
- whether it’s a burstable CPU plan (performance may drop after credits are exhausted)
No mention of test methodology
If a provider doesn’t show:- command lines used
- runtime
- file sizes
- direct I/O vs cached
---
Synthetic vs real-world performance: how to reconcile
Benchmarks isolate components; real applications combine them:
- A web request might be CPU-light but disk-latency sensitive (PHP + database).
- A database might look great on sequential throughput but struggle on random writes with high tail latency.
- A VPS can score high in sysbench but still “feel slow” if disk latency is poor or the CPU is heavily contended at peak times.
- Use sysbench/fio/iperf3 to shortlist providers and plans.
- Then run a small representative test:
---
Quick interpretation cheat sheet
- Sysbench CPU events/s: higher = faster compute (compare same settings)
- Sysbench memory MiB/s: higher = better memory throughput (secondary signal)
- fio 4k random IOPS + 99th latency: key for DB/app responsiveness
- fio sequential MB/s: key for large file transfers/backups
- iperf3 bandwidth: path-dependent; repeat tests; check retransmits for stability