Disclosure: We earn commissions from partner links. This doesn't affect our rankings. Learn more

Reviewed against the primary documentation linked below on 1 November 2026.

VPS Benchmark Guide: Run Repeatable Server Tests

A useful VPS benchmark records enough context for another person to repeat it. This guide gives you one controlled process for CPU, disk and network tests. It does not publish a provider leaderboard because VPSchart does not have a reproducible raw dataset that supports one.

What a comparable VPS benchmark must control

Use the same operating-system image, kernel, tool versions, plan class and test duration for every server. Record the provider, exact plan, region, CPU model, virtualization details and UTC time before each run. A shared CPU result is not directly comparable with a dedicated CPU result.

Keep constant

Operating-system image and updates
Kernel and benchmark tool versions
vCPU and memory target class
Test duration, block size and queue depth
Network peer, direction and protocol

Record for every run

Provider, plan and region
Shared or dedicated CPU category
CPU model and reported core count
UTC start time and tool version
Raw output and any failed run

Install the tools on Ubuntu or Debian

Run benchmarks on a disposable or newly provisioned server. The disk test writes a temporary file and can consume storage and I/O capacity. Do not run it on a busy production host or against a database volume.

sudo apt update
sudo apt install -y sysbench fio iperf3

Capture the environment before the first run:

date -u
uname -a
lscpu
free -h
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sysbench --version
fio --version
iperf3 --version

1. Measure CPU with sysbench

sysbench includes a CPU test and supports explicit worker threads, run time and warmup time. Use all reported processors, exclude the first ten seconds from the statistics and keep the command identical on each server.

sysbench cpu \
  --threads="$(nproc)" \
  --time=60 \
  --warmup-time=10 \
  run

Run the command at least three times and report the median events per second. Repeat the set at different UTC times if you are testing shared CPU plans. A single burst cannot show noisy-neighbor variation or sustained CPU policy.

2. Measure disposable-file I/O with fio

fio can model a defined I/O workload and report throughput, IOPS and latency. The command below uses direct I/O against one explicit 1 GB file in the current user's home directory. It does not test an entire block device.

fio --name=vpschart-randrw \
  --filename="$HOME/vpschart-fio-test.bin" \
  --size=1G \
  --rw=randrw \
  --rwmixread=70 \
  --bs=4k \
  --ioengine=libaio \
  --iodepth=32 \
  --direct=1 \
  --time_based=1 \
  --runtime=60 \
  --group_reporting

Save the complete output. After confirming that the path is exactly the temporary file above, remove it:

rm -f "$HOME/vpschart-fio-test.bin"

The result describes this workload, filesystem and storage path. It is not a universal disk-speed score. A database, sequential backup and small random-write workload need different fio jobs.

3. Measure network throughput with a controlled iperf3 peer

iperf3 requires a server and a client. Use a peer you control in a documented location. Random public peers can be congested, rate-limited or routed differently between providers, which makes the comparison unreliable.

Start the listener on the controlled peer:

iperf3 -s

Then run both directions from the VPS and save the JSON output:

iperf3 -c <CONTROLLED_SERVER> --time 30 --json
iperf3 -c <CONTROLLED_SERVER> --time 30 --reverse --json

The default direction sends from client to server. The reverse option makes the server send to the client. Record both, because an upload result does not establish download performance.

How to turn raw runs into a fair comparison

Provision like-for-like plans. Match vCPU, memory, CPU category and region as closely as the products allow.
Use one frozen command sheet. Do not change duration, concurrency or I/O settings after seeing an early result.
Keep every raw output. Store tool versions, UTC time, machine details and failures next to the result.
Run at least three repetitions. Use the median for the summary and retain the spread so unstable performance stays visible.
Repeat shared-host tests over time. Morning, evening and another day provide more evidence than three immediate reruns.
Interpret the real workload separately. Synthetic tests isolate components. They do not replace an application load test.

Dimension	Primary output	Keep with the result	Common mistake
CPU	Events per second and latency	Threads, CPU model, run time and warmup	Comparing shared and dedicated CPU as one class
Disk	IOPS, bandwidth and latency	Read/write mix, block size, depth, file size and direct-I/O setting	Calling one 4k random job a universal disk score
Network	Forward and reverse throughput	Peer, locations, route, duration and direction	Using different or uncontrolled public peers

Provider architecture changes how you read a result

The three commercial paths below are not ranked. They illustrate why the exact product class belongs in every benchmark record. Check current terms and availability for your region before buying.

Hetzner Cloud

Shared Resources and Dedicated Resources server types

Record the exact server type and CPU category. Hetzner says public IP addresses are separate from the server price, so compare the complete configuration rather than a headline price.

Read provider guide Check current plans

DigitalOcean Droplets

Shared CPU and Dedicated CPU Droplet plans

DigitalOcean recommends choosing from the real workload. Do not compare a shared Basic Droplet with a CPU-Optimized plan as if they were the same product class.

Read provider guide Check current plans

Hostinger VPS

KVM VPS plans with a documented CPU credit system

A short burst can reflect available credits rather than sustained capacity. Hostinger says available CPU drops temporarily when credits are exhausted, so repeat longer tests and record the timing.

Read provider guide Check current plans

The current-plan buttons are affiliate links. VPSchart may receive compensation after a qualifying purchase. That does not turn an unmeasured provider into a benchmark winner.

Use a result sheet that another person can audit

Keep one row per raw run. Do not overwrite a failed or unusually slow run. A compact record should contain at least:

run_id utc_started_at provider plan region cpu_class cpu_model tool_version command raw_output_path status notes

Only create a summary after the raw records are complete. Publish the median together with the number of runs and the date range. If a provider changes the plan or host class, start a new series rather than merging incompatible results.

Continue with a decision, not a synthetic winner

How VPSchart evaluates providers Estimate the complete VPS cost Compare operating responsibility Choose a VPS for development work

Primary sources checked

These sources were checked on 1 November 2026. Benchmark tools and provider policies can change, so recheck the documentation before starting a new comparison series.