VPS Tutorials
How to Benchmark a VPS (2026): Reading YABS, fio, iperf3 and Geekbench Results
Many people buy a VPS and immediately run a script, screenshot it and post it in a group chat: CPU score this, disk this many MB/s, network hitting several Gbps, and then conclude whether the machine is worth it. The problem is that running benchmarks isn't hard — understanding what they mean is. YABS, fio, iperf3 and Geekbench measure different dimensions, and looking at any one of them alone makes it easy to misjudge.
Many people, after buying a VPS, don't deploy anything first — they run a round of tests.
That's normal.
After all, you just got a machine, and what you most want to confirm is probably just these things:
- Whether the CPU is overprovisioned or mislabeled
- Whether the disk "looks fast but drops as soon as you actually write"
- Whether the network looks good during the day and collapses at night
- Whether this machine is actually suitable for your workload
And that's exactly where the problem lies.
Many people run a script and then jump straight to conclusions:
- This machine is powerful
- This machine isn't worth it
- This provider is stable
- This VPS is a beast
But the truth is usually not that simple.
Because YABS, fio, iperf3 and Geekbench measure different things, and if you mix them together or look at just one number, it's easy to misjudge.
So this article isn't just about "how to run" — the focus is more on:
- What each tool actually measures
- Which results are most easily misread
- Which results are more useful for websites, development, downloads, databases and proxy workloads
- After a full round, how you should actually make a judgment
1) The conclusion first: benchmarking isn't for screenshots, it's for judging "is this machine suitable for my scenario"
The biggest problem with many VPS benchmarking articles is that they turn benchmarking into a leaderboard game.
But for most users, there's really only one useful question:
- Can this machine handle my real workload?
So before running tests, don't rush to execute commands — first figure out what you want to verify.
You should care more about:
- Single-core performance
- Disk random read/write
- Network stability
You should care more about:
- Outbound bandwidth
- Long-duration network throughput
- Disk sequential writes
You should care more about:
- CPU stability
- Random I/O
- Behavior under memory pressure
So benchmarking isn't about "which tool is more advanced", it's about:
- Using the right tool to test the capability you'll actually use.
YABS is popular for a simple reason:
- One command runs it
- CPU, disk, network and Geekbench all come out along the way
- Great for an overview the first time you get a machine
Typical run:
curl -sL yabs.sh | bash
It gives you some fairly common results:
- Basic CPU info
- fio disk tests
- Network speed tests
- Geekbench in some environments
- Convenient
- Fast
- Good for a first checkup
Many people treat YABS as the "final conclusion".
That's wrong.
Because YABS is more like:
- An overview entry point
Rather than:
- An in-depth diagnostic tool
If you just want to know roughly what level this machine is at, YABS is fine.
But if you really want to judge disk quality, network throughput or long-duration CPU load capability, YABS is only the beginning, not the end.
Disk tests are the easiest to misunderstand.
Many people get excited when they see results like:
- 3000 MB/s
- 5000 MB/s
- 7000 MB/s
And then think:
- This disk is amazing
The problem is, these numbers usually only show one thing:
- Sequential read/write looks great
But in real workloads, many bottlenecks don't come from there.
- Random read/write
- Small-block I/O
- Stability under high concurrency
That's also why fio results can't be judged by a single maximum value.
What's more meaningful is looking at:
- 4K random read/write
- IOPS
- latency
- Whether it drops badly at different block sizes
Some VPS have great sequential writes, but:
- Random writes are mediocre
- Latency fluctuates a lot
- Speed drops after writing for a while
For running logs, databases or frequent cache writes, such a machine will feel completely different.
So when looking at fio, don't just look at:
- The highest MB/s
Look more at:
- Whether this disk is stable with real small files and small-block writes.
If you only glance at the benchmark chart, it's easy to mistake a disk "good for large-file sequential transfer" for one "good for all workloads".
4) What to look at in iperf3: it measures network throughput, not the whole public-internet experience
iperf3 is very valuable, but also one of the most easily misused tools.
The question it's best at answering is:
- How much network throughput exists between two points
For example:
iperf3 -c <server-ip>
Or the reverse test:
iperf3 -c <server-ip> -R
- Testing internal network bandwidth
- Testing throughput from a fixed probe to the VPS
- Comparing network capacity changes across different time periods
- "All my global users will get this speed"
- "The provider's public network must be this strong"
- "It tested 5Gbps, so real downloads must be 5Gbps"
Because iperf3 measures:
- A specific test endpoint
- Specific route conditions
- A specific time window
This means the same VPS:
- May test very strong to Tokyo
- May be average to Los Angeles
- May be completely different toward mainland China at evening peak
So the core value of iperf3 isn't proving "how amazing I am", it's:
- Helping you see whether there's a bottleneck in a particular network direction.
If you want to judge public-network route quality, iperf3 is best combined with:
pingtraceroutemtr
and looked at together.
For related network testing ideas, continue reading:
Geekbench's biggest value is giving you a fairly standardized CPU reference score.
What it's good for:
- Roughly comparing single-core and multi-core capability across machines
- Judging roughly what tier this VPS's CPU is in
- Helping identify machines with "great specs but weak single-core"
This matters for many scenarios, such as:
- WordPress
- Small APIs
- Panels and backend services
- Lightweight development environments
Because these scenarios are often sensitive to single-core performance.
It can't directly tell you:
- Whether it will throttle under long high load
- Whether it will jitter when neighbors grab resources
- Whether disk and network will drag it down
- Whether your real application will run smoothly
So Geekbench is more like:
- A CPU capability reference line
Rather than:
- A real-workload conclusion for the whole machine
If a machine has a decent Geekbench score but a bad disk, poor network and heavy host contention, the real experience can still be mediocre.
If you don't want to make the process too complicated, I suggest this order.
Goal:
- Quickly see the rough level of CPU, disk and network
- Judge whether there's any obvious anomaly
Goal:
- Judge disk random I/O and latency
- See whether there's a "good sequential write, much worse random" situation
Goal:
- Test network throughput in the direction you actually care about
- Compare differences across nodes and time periods
That is, don't just look at whether the Geekbench score is high — think about one thing:
- Does your workload depend more on single-core, on I/O, or on network
The benefit of this order is:
- You won't be led along by a single script
- You won't force the numbers from each tool into one "overall strength value"
Here's a more practical judgment framework.
This usually means the problem isn't raw compute, but possibly:
- Disk latency
- Host contention
- Network instability
Such a machine for:
- Large-file downloads
- Cold data storage
may be fine.
But for:
- Databases
- Dynamic sites
- High-frequency cache writes
it may not be comfortable.
This means:
- What you tested is single-path throughput
- Not the complete user experience
At this point you should go back and check:
- MTR
- Inbound/return routes
- Evening peak behavior
This kind of fluctuation is sometimes more worrying than "not high on average".
Because it often means:
- Unstable resources
- Big neighbor impact
- Uneven host load
And what real workloads fear most is often not "medium", but "unstable".
Prioritize:
- Single-core score
- 4K random I/O
- Network stability
Prioritize:
- Single-core + multi-core stability
- Disk random read/write
- Latency fluctuation
Prioritize:
- Outbound throughput
- Long-duration bandwidth stability
- Large-file sequential read/write
Prioritize:
- Overall CPU performance
- Disk fundamentals
- Whether the machine is stable
Only when you match "workload type" with "tool output" do benchmark results truly become meaningful.
Many VPS look good in benchmarks but are in a completely different state at night.
This is especially common in:
- Cheap shared VPS
- Highly contended hosts
- High-bandwidth but congested-at-peak routes
So a more reliable approach is:
- Run once during the day
- Run again at evening peak
- Compare the difference at least once
Especially when you're looking at:
- Network throughput
- Latency jitter
- Host fluctuation
If results fluctuate a lot, even a high peak isn't necessarily more worth keeping than a machine that's "less dramatic but more stable".
If you later want to see quarterly cross-sectional data, you can also check:
10) Final word: the point of benchmarking isn't "scoring high", it's "understanding how this machine will affect your workload"
YABS, fio, iperf3 and Geekbench all have value.
But their real meaning isn't to let you post screenshots on social media or in group chats — it's to help you answer this question:
- Is this VPS actually suitable for my real scenario?
So the most reliable order is always:
- First figure out what you're testing
- Then see what signals each tool gives you
- Finally map the results back to your workload needs
As long as you do this, benchmarking will no longer be "running a bunch of numbers and getting more confused", but a step that truly helps you make decisions.