All-in-One VPS Benchmark with bench.sh

bench.sh (commonly shared from teddysun) is popular because it's fast and produces a single, readable report. Treat it as a sanity check for a new VPS, not as an audit-grade benchmark.

Quick Summary

• Use bench.sh for first boot validation and rough comparisons.
• Do not use it to "prove" production performance (especially for DB and WordPress workloads).
• If you need repeatable numbers: use fio for disk, iperf3 for network, and sysbench for CPU/DB-like testing.

warning

Avoid piping untrusted scripts into bash. If you run wget ... | bash or curl ... | bash, you are executing remote code immediately. Download the script first, inspect it, then run it.

Safer way to run

Download, inspect, then execute:

run-bench-sh-safely.sh

mkdir -p ~/bench
cd ~/bench

wget -O bench.sh https://raw.githubusercontent.com/teddysun/across/master/bench.sh
sed -n '1,200p' bench.sh

bash bench.sh | tee bench.$(date +%F_%H%M%S).log

Example output

What the report can (and cannot) tell you

What it can tell you:

• CPU is generally functional and not throttled into unusability.
• Disk is not completely broken (very rough sequential read/write signal).
• Basic connectivity exists to a set of public endpoints.

What it cannot tell you:

• How WordPress behaves under concurrency (PHP-FPM, MySQL, cache hit rates).
• How the disk behaves under random I/O or queue depth (DB writes).
• Whether your network meets an SLA (routing and endpoint selection dominate).

Decision-oriented evaluation

Use case	Verdict	Why
First-time VPS sanity check	Best fit	Fast, minimal setup, quick signal
Comparing multiple low-cost VPS plans	Acceptable	Useful for rough comparisons only
Sharing on forums	Acceptable	Output format is widely recognized
Production performance validation	Not suitable	Too shallow and environment-dependent
Disk performance analysis	Not suitable	Sequential-only, unrealistic workload
Network SLA validation	Not suitable	Public endpoints, no control
Client/audit reports	Not suitable	No controlled methodology or repeatability

Strengths

• Extremely fast to run
• No install dependencies in most environments
• Human-readable single report
• Common baseline across VPS communities

Limitations

• Disk tests are simplistic and do not represent database I/O
• Network results vary heavily by geography and routing
• No workload profiles (no concurrency, no mixed read/write)
• No structured output for automation (JSON/CSV)
• Easy to misinterpret as "real performance"

Credibility scale (rule of thumb)

Category	Credibility	Notes
CPU	Low to medium	Synthetic snapshot; not workload-specific
Disk I/O	Low	Sequential only; no queue depth/random I/O
Network	Low	Public mirrors; selection bias
Repeatability	Low	Results vary between runs
Automation	Low	Output is not machine-friendly
Human readability	High	Clear, compact summary

When to use it

• Immediately after provisioning a new VPS
• When you want a quick "is this box totally broken?" test
• When you want a rough baseline before/after a hosting move

When not to use it

• When you are tuning a WordPress stack (OLS/Nginx, PHP-FPM, MySQL)
• When you need audit-grade or client-facing evidence
• When you need to test real-world I/O patterns

Better next steps (repeatable tools)

If bench.sh output looks suspicious or you need real numbers, use:

• Disk: fio
• Network: iperf3 (between two controlled hosts)
• CPU: sysbench cpu
• DB-like: sysbench oltp_read_write (against a test DB)