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.
cd ~
curl -fsSL https://yabs.sh -o yabs.sh
less yabs.sh
bash yabs.sh -hRun 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.
bash yabs.sh | tee yabs-$(date +%F).txtRead 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.
mkdir -p ~/benchmarks && mv yabs-*.txt ~/benchmarks/
ls ~/benchmarksWhat 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.