VPS Performance Benchmarking with fio sysbench iperf3

You just rented a VPS. The specs looked good on paper: 4 vCPUs, 8GB RAM, an NVMe drive, and a gigabit port. But numbers on a pricing page mean nothing until you run the tests yourself. The disconnect between advertised performance and real-world throughput can be brutal, especially on shared hosts where your neighbor's database spike eats your IOPS. This post covers the three tools I use on every fresh Linux VPS before migrating anything onto it: fio for disk I/O, sysbench for CPU and memory, and iperf3 for network bandwidth.

Prerequisites

• A Linux VPS running Ubuntu 24.04 LTS or Debian 12 (commands are the same for both).
• Root access or a sudo-enabled user.
• No other heavy workloads running during the test (database, application, cron jobs).
• For iperf3: a second machine or another VPS to act as the server endpoint, your home machine works if you know its public IP.

Why You Should Benchmark a VPS Before Using It

Virtualization layers add overhead. A burstable CPU on a cheap plan might look like 4 cores but collapse when under sustained load. NVMe storage can be throttled if the hypervisor oversubscribes IOPS. Network ports are rarely dedicated, your 1Gbps link may drop to 200Mbps during peak hours. Benchmarking gives you a baseline you can trust and a point of reference when performance degrades later. If your 4GB RAM VPS suddenly feels sluggish six months in, re-running these tests tells you whether the host degraded or your application grew. Without a baseline, you are troubleshooting blind.

The tools I will show are lightweight, non-intrusive, and standard on most Linux distributions. Install them, run each test, record the results, and save them somewhere. Your future self debugging a slowdown will thank you.

Step 1, Install the Benchmark Tools

All three tools are in the default repositories for Debian and Ubuntu. One apt invocation gets everything:

sudo apt update
sudo apt install fio sysbench iperf3 -y

Verify each installation:

fio --version
sysbench --version
iperf3 --version

You should see version strings for all three. If sysbench fails to start, install it from the official repo, some older Ubuntu versions ship a broken package. On Ubuntu 24.04 and Debian 12, this is not an issue.

Step 2, Disk I/O Testing with fio

Do not use dd for disk benchmarks. dd tests sequential writes in a cache-warm scenario and tells you almost nothing about real workloads. fio is the standard: it tests random reads, random writes, mixed workloads, and different queue depths. It bypasses the page cache correctly and gives repeatable results.

The test below runs a 4GB file with a 4KB block size (common for database pages, logs, small-file operations) at a queue depth of 32. This simulates a moderately busy workload:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test \
    --bs=4k --iodepth=32 --size=4G --readwrite=randrw --rwmixread=75 \
    --output=fio-benchmark.log

What each flag does:

• --direct=1, bypasses the OS page cache, forcing true disk I/O.
• --ioengine=libaio, uses asynchronous I/O (the kernel AIO interface).
• --bs=4k, block size of 4KB, representative of many database workloads.
• --rwmixread=75, 75% reads, 25% writes (a typical database or web app pattern).
• --size=4G, the file is 4GB, enough to exhaust any NVMe-level DRAM cache.

The output goes into fio-benchmark.log. Pull the three numbers you care about:

grep -E "(read|write|iops|latency)" fio-benchmark.log

What to expect: On a good NVMe VPS (like the ones at thueVPS), mixed random read/write at 4KB block size should give 40,000-80,000 IOPS and sub-500µs average latency. On a cheaper SATA SSD, you might see 5,000-15,000 IOPS. Anything below 3,000 IOPS with --direct=1 suggests throttling or a spinning disk. If you see IOPS over 500,000, your cache is not bypassed, double-check --direct=1 is working.

Step 3, CPU and Memory Stress with sysbench

Sysbench is my go-to for CPU and memory stress. It is not as synthetic as Geekbench and far more configurable. It runs on the host without any benchmarking daemon or phoning home.

CPU test, prime number computation (single-threaded and multi-threaded):

sysbench cpu --cpu-max-prime=20000 run

This calculates prime numbers up to 20,000. The result shows total time in seconds:

# Example output:
events per second:   347.13
total time:          10.0008s
total number of events: 3472

Higher events per second is better. Compare against known results: a modern Xeon (like the Intel E5-2670 on dedicated server hardware) does about 300-400 events per second for a single thread at this setting. A burstable vCPU might start at 350 and drop to 200 after a few seconds, watch the output for throttling patterns.

For multi-threaded testing, match the thread count to your vCPU count:

sysbench cpu --cpu-max-prime=20000 --threads=4 run

A 4GB RAM VPS should show a roughly linear speedup with threads. If performance does not scale, you may be on an oversubscribed hypervisor.

Memory test: This benchmarks sequential read/write throughput in the host RAM:

sysbench memory --memory-block-size=1M --memory-total-size=10G run

Expected numbers: DDR4 RAM in a modern VPS host should deliver 8-12 GB/sec for reads and 4-6 GB/sec for writes. Numbers far below that suggest NUMA misconfiguration or an old host platform.

Step 4, Network Bandwidth and Latency with iperf3

Iperf3 tests raw TCP/UDP throughput between two endpoints. You need a server and a client. If you have two VPS accounts, use one as server and the other as client. If you only have one VPS, run iperf3 from your local machine with the VPS as the server, but your home ISP may be the bottleneck.

On the VPS (server side):

iperf3 -s

This starts iperf3 in server mode, listening on port 5201. Open that port in your firewall temporarily:

sudo ufw allow 5201/tcp

On your client machine (or a second VPS):

iperf3 -c <VPS_IP> -t 30

The -t 30 flag runs the test for 30 seconds. At the end, iperf3 reports the sum of the connection and the retransmit count. What to look for:

• Bandwidth, Should match your VPS plan: 1Gbps means close to 940-980 Mbps (TCP overhead takes the rest).
• Retransmits, A small number (0-5) is fine; hundreds of retransmits during a 30-second run indicate packet loss on the path. This could be the hypervisor, the upstream provider, or your own connection.
• Jitter (UDP test), Run iperf3 -c <IP> -u -b 100M -t 30 to test 100 Mbps UDP. Jitter under 1ms is excellent. Above 10ms suggests network congestion.

Step 5, Interpret Your Results and What They Mean

You now have three numbers: IOPS, CPU event rate, and network throughput. Here is how to read the story they tell together.

• High IOPS, low network, The storage is fast, but the network port is throttled. Good for database servers, bad for content delivery.
• High network, low IOPS, The disk is the bottleneck. Your app will seem snappy at first, then degrade as the page cache fills.
• CPU events per second drop under multi-thread load, The hypervisor may be oversubscribed. Your VPS is sharing physical cores with noisy neighbors.
• Retransmit rate above 0.5% of total packets, The provider's network is unreliable or congested. This will cause TCP throughput fluctuations in production.

Record these values in a plain text file. When you open a support ticket later, attach the baseline. It forces the provider to take the issue seriously, "my 4GB RAM VPS is running at half its original IOPS" is harder to dismiss than "my server is slow".

For readers looking for a reliable VPS in Vietnam, places like thueVPS use NVMe storage with dedicated IPv4 and transparent network provisioning. After running these tests on their infrastructure, I found the IOPS and bandwidth matched the advertised specs within a 5% margin, which is rare in the shared hosting world. The point is not to recommend blindly, but to equip you with the tools to verify claims yourself.

Troubleshooting Common Benchmark Pitfalls

"fio says 0 IOPS." You are likely running a kernel without libaio support or missing the package. Reinstall with sudo apt install --reinstall libaio1. Switch to --ioengine=posixaio as a fallback.

"sysbench memory test shows less than 2 GB/s." You may be hitting the SWAP boundary. Run free -h before the test. If swap usage is above zero, disable it temporarily: sudo swapoff -a. After the test, re-enable with sudo swapon -a.

"iperf3 refuses connection, connect failed." The firewall is blocking port 5201. Check with ss -tlnp | grep 5201 to confirm the server is listening. Then run ufw status to see if the rule is missing. Cloud providers like DigitalOcean also have a panel-level firewall, check the control panel.

"Performance fluctuates wildly between runs." Run each test three times and take the median. A single run can be skewed by background noise (a cron job, another tenant's burst on the hypervisor). The median value over three runs is a much more reliable baseline than the best run.

FAQ

Related articles

• Configure Swap and Optimize Memory on a Low RAM VPS
• Security Audit and Hardening with Lynis on a VPS
• Set Up a Prometheus Alertmanager Pipeline on a VPS
• Install aaPanel on Linux Ubuntu 24.04 or Debian 12 VPS