How to benchmark a VPS: CPU, disk and network tests

Step 1. Find out what is inside the server

Before measuring, check that you got what you pay for: the CPU model and vCPU count, RAM and disk size. Five standard commands are available on any Linux:

lscpu
nproc
free -h
lsblk
df -h

• lscpu - CPU model (Model name), processor count (CPU(s)), instruction flags such as avx2 and avx512f, virtualization type (Hypervisor vendor).
• nproc - how many processors the system can use; on a VPS this is the plan's vCPU count.
• free -h - memory: total is the full amount, available is how much programs can still take.
• lsblk and df -h - disks, partitions and free space. Inside a virtual machine the disk is usually named vda or sda, even when it is physically NVMe.

Step 2. CPU: sysbench on one and on all threads

sysbench cpu computes prime numbers and reports how many such jobs the CPU completes per second - the events per second line. Run the test twice: on one thread to see single-core speed, and on all threads to see the power of every vCPU.

sudo apt update
sudo apt install -y sysbench
# one thread: single-core speed
sysbench cpu --threads=1 --time=10 run
# all threads: combined power of every vCPU
sysbench cpu --threads=$(nproc) --time=10 run

The single-thread result matters more for websites, bots, game servers and databases: one request runs on one core. The multi-thread result should grow roughly in proportion to the vCPU count; if on 4 vCPUs it is barely higher than single-thread, check steal time (step 5) - the host is likely overloaded. Why per-core clock matters so much is covered in AMD Ryzen 9 5950X vs 9950X.

Step 3. Disk: fio

fio is the standard disk testing tool. The three runs below create a 1 GB file fio-test in your home directory and read and write it for 30 seconds. The --direct=1 flag bypasses the OS cache so the disk is measured rather than memory; --bs is the block size, --iodepth is how many requests are kept in flight at once.

sudo apt install -y fio
cd ~
# random reads in 4 KB blocks
fio --name=randread --filename=fio-test --size=1G --direct=1 --ioengine=libaio --rw=randread --bs=4k --iodepth=64 --runtime=30 --time_based --group_reporting
# random writes in 4 KB blocks
fio --name=randwrite --filename=fio-test --size=1G --direct=1 --ioengine=libaio --rw=randwrite --bs=4k --iodepth=64 --runtime=30 --time_based --group_reporting
# sequential reads in 1 MB blocks
fio --name=seqread --filename=fio-test --size=1G --direct=1 --ioengine=libaio --rw=read --bs=1M --iodepth=16 --runtime=30 --time_based --group_reporting
# delete the test file
rm fio-test

In the output, look at IOPS= (operations per second), BW= (throughput) and clat latency - its percentiles show how long the slowest requests waited. For databases and builds, 4 KB IOPS and latency matter more; for backups and file serving, sequential speed does. How NVMe differs from SATA SSD on these numbers is covered in NVMe vs SATA SSD vs HDD.

Step 4. Network: iperf3 between your own servers

iperf3 measures the throughput between two machines you control. One server receives (-s), the other sends (-c); the -R flag reverses the direction. If the installer asks whether to run iperf3 as a daemon, answer «No».

sudo apt install -y iperf3
# on server A: temporarily allow server B to port 5201 and start listening
sudo ufw allow from SERVER_B_IP to any port 5201 proto tcp
iperf3 -s
# on server B: upload to A, then download from A (-R)
iperf3 -c SERVER_A_IP -t 30
iperf3 -c SERVER_A_IP -t 30 -R

After the test, stop iperf3 -s (Ctrl+C) and remove the rule: sudo ufw status numbered, then sudo ufw delete <number>. Public speedtest services and the speedtest-cli tool from the repository are convenient, but draw conclusions carefully: the result depends on the chosen test server, its load and the route to it, not only on your VPS.

Step 5. Steal time: is the host overloaded?

Steal time is the share of time a virtual CPU is ready to run but the hypervisor gives the physical core to other machines. It is the st column in vmstat and the st value in the %Cpu(s) line of top:

# five samples one second apart, the st column
vmstat 1 5
# in top: the %Cpu(s) line, the st value
top

Near zero is normal. If st stays noticeably above zero, especially under your own load during sysbench, your VPS shares cores with overloaded neighbours: tests will fluctuate and programs will slow down for no visible reason. That is a reason to show the vmstat output to the provider's support.

An all-in-one test: the YABS script

YABS (Yet Another Bench Script) is a popular script that in one run collects system information and runs disk (fio), network (iperf3 to public servers) and CPU (Geekbench) tests. It is usually run as a one-liner, curl -sL yabs.sh | bash, but it is safer to download and read it first:

curl -sL yabs.sh -o yabs.sh
less yabs.sh
bash yabs.sh

How to read VPS benchmark results

How to check a Tihost VPS

A Tihost server is deployed in about 2 minutes after payment, so you can run every measurement within the first hour. Inside is KVM with full root access: lscpu shows an AMD Ryzen 9 5950X or 9950X depending on the location, and lsblk shows the NVMe disk attached as a virtual device. How much RAM and how many vCPUs a task needs is covered in How much RAM a VPS needs.