MonitoringWritten by GLWS12 min readUbuntu 24.04 LTS / AlmaLinux 9
Commands run on your server unless a section says otherwise. Replace example usernames, addresses and paths with your own values. Keep a working session open when changing remote access.

What a benchmark is good for

YABS is a free script that runs a disk test with fio, network speed tests with iperf3 and a CPU test with Geekbench, then prints a summary. It is popular for comparing VPS plans because it takes one command and gives numbers you can put side by side.

Benchmarks measure a server at one moment, under particular conditions. They are useful for spotting a problem, such as disk speed far below what you expect, and for rough comparisons. They do not tell you how your own application will perform.

Prepare and read the script before you run it

The usual instruction pipes a download straight into a shell. Download the script, read it, and then run it. It downloads and runs Geekbench and fio, and it contacts public iperf3 servers, so the server needs outbound internet access. Run it when the server is quiet, and do not run it on a production server during busy hours, because it uses all your CPU and disk for several minutes.

Both systems
cd ~
curl -fsSL https://yabs.sh -o yabs.sh
less yabs.sh
bash yabs.sh -h
The -h option lists the current flags. Useful ones are usually to skip the Geekbench test, to skip the network test or to use fewer iperf locations. Check what your version supports.

Run it

Run the full benchmark and save the output to a file so you can compare later. It takes several minutes. The Geekbench test uploads its result to the Geekbench Browser and prints a link. If you do not want that, skip the Geekbench part with the relevant flag.

Both systems
bash yabs.sh | tee yabs-$(date +%F).txt
Geekbench results are public by link and are sent to a third party. Skip that test if you prefer.

Read the basic information

The first block lists the processor model, number of cores, clock speed, whether AES-NI and virtualisation extensions are available, memory, swap and disk size. Check that the cores and memory match your plan. The processor model tells you what generation of hardware you are on, which matters more than the clock speed on its own.

Read the disk results

The fio test reports read and write throughput and IOPS at several block sizes. Large blocks, such as 1 MB, show sequential throughput, which matters for backups and large files. Small blocks, such as 4 KB, show operations per second, which matters for databases. NVMe storage should be well above SATA and spinning disks, but virtualisation and host load can reduce it. Run it twice at different times, because one low result can be a busy neighbour.

Read the network results

The iperf3 section shows upload and download speed to public servers in several regions. Speed to a nearby location is a fair test of your port, while distant locations are limited by routing and the other end. A 1 Gbps port rarely hits 1 Gbps to far-away public servers, and busy public iperf3 servers are themselves a bottleneck, so one slow result proves little. Look for consistent differences between locations and between runs.

Read the Geekbench results

Geekbench gives a single-core and a multi-core score. Single-core matters for tasks that cannot use many cores, such as a single database query or one web request. Multi-core matters for parallel work. Use the scores to compare servers with the same test version, as scores from different Geekbench versions are not comparable, and remember shared vCPUs deliver less when the host is busy.

Compare fairly

Compare like with like: the same script version, the same Geekbench version, the same time of day, and ideally several runs. A single result is a snapshot, so repeat the test on a different day and take the typical result. Record the plan, location and date beside each result. Do not compare a VPS result with a dedicated server, or a result at midnight with one during peak hours.

Keep results together
mkdir -p ~/benchmarks && mv yabs-*.txt ~/benchmarks/
ls ~/benchmarks

What benchmarks cannot tell you

They do not show how your application behaves with real data and real users, how consistent performance is over weeks, the quality of support or the network path to your own visitors. For that, test your own workload: load a copy of your site, run your own database queries, and measure response times from where your users are. Use the benchmark as a first screening and your own tests as the decision.

Official documentation

These upstream references provide more detail on the commands and workflows in this guide.