YABS: benchmarking a Linux VPS with one bash script

The problem YABS solves for VPS buyers

Comparing two VPS plans from a spec sheet tells you almost nothing. The CPU model is shared, the disk is network-attached, and the port is oversubscribed. The only way to know what you are renting is to measure it, and measuring it properly means running fio for disk, iperf3 for network and Geekbench for CPU and memory. That is three tools, three sets of flags, and a fair amount of reading before the first number appears.

YABS collapses that into one command. The README describes it as an attempt to automate "the best benchmarking tools in the industry", and the target audience is clear: people who rent Linux servers and want a repeatable profile of them. Because the output is standardised, results from different machines can be compared side by side, and the -j and -w flags turn the whole run into JSON for a database.

The project is a shell script with a bin/ directory holding prebuilt binaries, plus a LICENSE and a yabs.sh entry point at the repository root. The last push to master was on 2026-09-20, and the same day produced releases for musl cross toolchains, iperf3 3.21 static binaries and fio 3.42 static binaries.

How the script runs fio, iperf3 and Geekbench without installing anything

The design constraint is that the tested machine gets nothing installed and needs no elevated privileges. The README states the script is built to require no external dependencies and no root. It achieves that by shipping static binaries in the repository and executing them directly, which is why the releases page carries prebuilt fio and iperf3 artefacts rather than source tarballs.

There is a precedence rule that matters when you read results. The README says that if the tested system already has fio or iperf3 installed, "the local package will take precedence over the precompiled binary". The -b flag reverses that and forces the bundled binaries. So two runs on the same hardware can execute different fio builds depending on what was already in PATH, and the version printed in the output is the only way to tell them apart.

The test set itself is fixed. Four random read and write fio jobs run at 4k, 64k, 512k and 1m block sizes, each split 50/50 between reads and writes, which the README frames as a near-real-world random workload rather than a sequential throughput figure. Network testing uses iperf3 with 8 parallel threads against several public locations, in both directions. If a server stays busy after 5 attempts, that location and direction is skipped rather than retried indefinitely. Geekbench 6 is the default CPU and memory test, with older and newer generations available through flags.

Running YABS on Ubuntu or CentOS: a first benchmark

There is no package to install. The README gives the entry point as a pipe from curl or wget straight into bash, which means the script is fetched and executed in one step:

curl -sL yabs.sh | bash

On a minimal Ubuntu or CentOS image this is the whole setup. You should see the network information block print first, followed by the fio disk results, the iperf3 results per location, and finally the Geekbench score with a URL for the full result. The wget form is equivalent:

wget -qO- yabs.sh | bash

Flags are passed through with -s --, which the README shows as the general pattern:

curl -sL yabs.sh | bash -s -- -flags

Flags can be grouped, so -fg skips both the disk and the system performance tests and leaves only the network run. Running with -h prints the help message along with the flags detected and the status of any local fio and iperf3 packages, which is the quickest way to confirm which binaries a run will use. To submit results to a collector, pass the endpoint with -s; the README shows multiple URLs joined by commas.

Bandwidth, ARM and the limits of a one-shot run

The most concrete limitation is traffic. The README warns that the default run performs many iperf tests and will try to max out the network port for roughly 20 seconds per location, 10 seconds in each direction. On a NAT VPS or any host with a monthly transfer cap, a default run is a real cost. The -r flag reduces the iperf locations to Scaleway and Clouvider in London and New York, and -i removes network testing altogether. Neither is the default, so the default is the expensive one.

ARM support is explicitly provisional. The README calls it experimental and says it is "not considered entirely stable due to limited testing on distinct ARM devices". If you are benchmarking an ARM instance, treat a failure or a missing test as expected rather than as a finding about the hardware.

Windows is not a supported target directly. The README says the script can run under WSL 2, and that WSL 1 will not run the script and binaries correctly. That is a narrow window, and a result produced under WSL 2 describes the virtualised environment as much as the host.

There is also a security dimension the README raises itself: the script relies on external binaries to complete the tests, and the network and disk tests use binaries built by GitHub Actions. Piping a remote script into bash and letting it execute downloaded binaries is a trust decision, and the README does not document signature verification for those artefacts.

YABS versus a general VPS benchmark script

The obvious comparison is with the other widely used VPS benchmark script, the one by Teddysun. Both are shell scripts that profile a rented server, and both are aimed at the same buyer. The difference is in what they treat as the unit of comparison.

YABS is built around named, versioned tools and a machine-readable result. The fio, iperf3 and Geekbench versions are pinned through the bundled binaries, the output can be emitted as JSON with -j or -w, and the README lists submission endpoints including YABSdb, VPSBenchmarks and serverlist.dev. That makes it a reasonable fit when you want to collect results from many machines and compare them later.

A broader benchmark script typically runs a wider spread of smaller checks and prints a human-readable summary. That is better when you want a general picture of a box you have just logged into. It is worse when you want to know whether two servers differ, because the individual numbers are not tied to pinned tool versions and there is no standard result format to diff.

The trade-off runs the other way too. YABS is narrow by design: four fio block sizes, iperf3 against a fixed set of public locations, and one Geekbench generation at a time. If your question is about something outside that set, YABS will not answer it, and no flag will make it.

Licence, maintenance and what an upgrade costs

The repository is licensed under the WTFPL, a permissive licence whose terms are unusually short. For a benchmarking script that you pipe into bash, the practical implication is that copying, modifying and redistributing it carries essentially no conditions. That is a licence question, not legal advice, and anyone embedding the script in a commercial product should read the licence text itself rather than a summary.

The repository is not archived, and the last push was on 2026-09-20. The README's own changelog shows the cadence: fio and iperf3 portable binary builds were automated through GitHub workflows on 19 Sep 2026, Geekbench 7 became available behind the -7 flag on 24 Jul 2026, and a usage statistics site appeared on 04 Jul 2026. Releases in September 2026 covered musl cross toolchains, iperf3 3.21 and fio 3.42.

Upgrade cost is close to zero for the user, because there is nothing installed to upgrade. Running the same curl command again fetches the current script, and with it the current bundled binaries. The cost sits on the other side: results are not reproducible across time unless you record which tool versions produced them. Anyone building a comparison over months should capture the fio and iperf3 versions from the run output, not just the scores.

Editorial conclusion

YABS fits anyone comparing VPS plans or checking a new server before putting it into service: one curl command, no root, no package installs. Skip it on metered or low-bandwidth hosts unless you pass -r or -i, and treat the ARM path as experimental, since the README calls it not entirely stable. Before you trust a number, check whether fio and iperf3 were already present, because the README says a local package takes precedence over the bundled binary, and that changes what actually ran.

Frequently asked questions

Official sources

1. Issues
2. License: WTFPL
3. masonr/yet-another-bench-script on GitHub
4. README
5. Releases