YABS: benchmarking a Linux VPS with one bash script
YABS - a simple bash script to estimate Linux server performance using fio, iperf3, & Geekbench
At a glance
- What is it?
- YABS wraps fio, iperf3 and Geekbench behind a single curl command, with no dependencies and no root. It is a quick way to compare VPS disk, network and CPU, as long as you accept the bandwidth bill and the RISC-V caveat.
- Who is it for?
- 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 RISC-V path as experimental, since the README calls it not entirely stable.
- Can I use it commercially?
- Yes. WTFPL is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 14, 2026, and from our analysis. They are not legal advice.
Star history
- masonr/yet-another-bench-script6,818 ★ · +112
| Repository | 2026-09-23 | 2026-11-14 |
|---|---|---|
| masonr/yet-another-bench-script | 6.7k | 6.8k |
112 Stars in the last 52 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
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-10-31, and recent releases include iperf3 3.22 static binaries (2026-10-02), fio 3.43 static binaries (2026-09-27) and iperf3 3.21 static binaries (2026-09-20).
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 -h flag reports the local package (fio/iperf) status.
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 | bashThe wget form is equivalent:
wget -qO- yabs.sh | bashFlags are passed through with -s --, which the README shows as the general pattern:
curl -sL yabs.sh | bash -s -- -flagsFlags 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.
RISC-V (riscv64) support is explicitly provisional. The README calls it experimental and says it is "not considered entirely stable due to limited testing on distinct RISC-V devices". If you are benchmarking a RISC-V machine, 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.
YABS versus a general VPS benchmark script
The obvious comparison is with other general-purpose VPS benchmark scripts. 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 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 Geekbench 6 by default, with other generations selected by flags. 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-10-31. 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. Recent releases covered iperf3 3.22 (October 2026), fio 3.43 and iperf3 3.21 (September 2026).
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 RISC-V 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
What is YABS?
YABS is a bash script that benchmarks Linux servers using fio for disk performance, iperf3 for network performance and Geekbench for CPU and memory. The README describes it as an attempt to automate the best benchmarking tools in the industry, and it is designed to run without external dependencies or elevated privileges.
How do you run a benchmark on Linux with YABS?
The README gives the entry point as curl -sL yabs.sh | bash, with wget -qO- yabs.sh | bash as an equivalent. Flags are passed through with bash -s --, as in curl -sL yabs.sh | bash -s -- -flags.
Is YABS the best Linux benchmarking tool?
The README does not make that claim; it presents the script as an attempt to automate existing tools rather than as a replacement for them. What it does offer is a fixed set of tests (four fio block sizes, iperf3 with 8 parallel threads, and Geekbench 6 by default) plus JSON output, so results from different servers can be compared.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/masonr-yet-another-bench-script)Star history chart for your README
[](https://hysenlabs.com/projects/masonr-yet-another-bench-script)Was this useful?