Server Benchmark Guide

Server Benchmark Guide: Prove Your VPS Is Worth the Money

Buying a server is a bit like buying a used phone — the "8 cores, 16 GB" on the spec sheet isn't always true. On a shared VPS, a noisy neighbor on the same host can cut your CPU frequency in half and drag your disk I/O down to single digits. That's why, in our server selection flow, the first thing you do after provisioning an instance isn't installing a control panel — it's running a full benchmark and judging with data instead of marketing copy.

Start with One All-in-One Script

If you only have time for one thing, run yabs.sh. It bundles Geekbench (CPU), fio (disk) and speedtest (network) into a single script that produces a full report in about fifteen minutes:

curl -sL yabs.sh | bash

The report includes single-core and multi-core Geekbench scores, 4K random read/write IOPS, and up/down bandwidth to nodes around the world. Compare that report line by line against the provider's advertised specs and overselling becomes obvious. Save the output to a file — it's now your baseline for every future comparison. Pair it with front-end tuning like font and asset optimization to squeeze out the last few percent for real users.

Reference: yabs source https://github.com/masonr/yet-another-bench-script; Geekbench https://www.geekbench.com/

CPU: sysbench and openssl

sysbench is the most common CPU load tool — apt install sysbench on Debian/Ubuntu, yum install sysbench on CentOS-based systems:

# Single core
sysbench cpu run

# All cores in parallel
sysbench cpu --threads=$(nproc) run

Single-core events/sec typically falls between 500 and 2000 depending on generation and clock speed. Two machines both labeled "4 cores" can differ by 30% in multi-core scores — that's the difference between real physical cores and overselling. If you're planning to run HTTPS, also check symmetric encryption throughput:

openssl speed aes-256-cbc

Whether AES-NI is enabled directly affects TLS handshake and file-encryption throughput, and the effect is especially visible on high-concurrency endpoints.

Memory and Disk: the Bottleneck Is Usually I/O

Cross-check memory with sysbench and mbw:

sysbench memory --memory-block-size=1M --memory-total-size=10G run
apt install mbw -y && mbw 256

Disk is where VPSes fail most often. Use fio to test sequential I/O (large files, video) and 4K random I/O (databases, dynamic pages) separately:

fio --name=randread --ioengine=libaio --direct=1 --bs=4k --size=2g --numjobs=4 --iodepth=64 --rw=randread --group_reporting
fio --name=randwrite --ioengine=libaio --direct=1 --bs=4k --size=2g --numjobs=4 --iodepth=64 --rw=randwrite --group_reporting

Keep --direct=1 — without it the page cache flatters the results and you're measuring RAM speed, not disk speed. If 4K random read IOPS stays below 5000 for long, the disk is either being hammered by neighbors or an HDD wearing an SSD costume.

It helps to know reasonable expectations per storage medium: NVMe SSDs typically do 50k+ 4K random read IOPS, SATA SSDs 20-40k, and HDDs often can't reach 200. If your machine is advertised as NVMe but benchmarks in the low thousands, it's either oversold I/O throttling or a noisy neighbor eating the bandwidth. Also note bursty I/O: many small providers sell short-lived peaks — a 30-second fio run and a 5-minute run can differ several-fold, and the longer run is closer to reality.

Network: Bandwidth and Latency Are Different Things

Bandwidth is measured with iperf3, which needs both ends: run iperf3 -s on the server and iperf3 -c <server_ip> -t 30 -P 4 on the client. The -P 4 opens four parallel streams to push closer to the real ceiling. For latency, curl shows each phase directly:

curl -w "TCP: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.com

Fast TCP handshake but a high TTFB usually means the origin is slow to process or packets are being retransmitted — the problem is the app, not the route.

To pin down route problems use mtr: mtr -rwz <target_ip>. It shows packet loss and latency hop by hop. If loss concentrates in the middle hops, that's backbone congestion, not your server; only if the final hop (your box) shows high loss should you go to the provider.

Reading the Results

A Real Case

One site owner bought a 2C2G promo instance from a small provider, advertised as "NVMe SSD." After running yabs he found 4K random read at just 3,000 IOPS — HDD territory. He sent the full report screenshot to support, who checked host load and swapped him onto another machine; the re-test hit 40,000 IOPS. Without that data, that argument had no chance of being won.

FAQ

• Results fluctuate wildly: VPS resources are shared — test during off-peak hours and take the median of a few runs.
• Do I need the full yabs every time? No. For routine monitoring, sysbench CPU plus a 4K random read test is enough, and takes minutes.
• Scores are fine but the site is still slow: Check network latency and packet loss first, then the app itself — don't blame the server right away.

16IDC Tips

1. Run a full yabs right after provisioning, save the output as your baseline, and compare it with the advertised specs.
2. If results are far below what was advertised, rule out neighbor interference first (re-test at another time), then ask for an instance swap or refund.
3. Re-run monthly and compare against the baseline. CPU score or disk I/O dropping by half usually means a new neighbor on the same host, or aging hardware — watch for this kind of performance degradation before it reaches users.
4. Match the test to the workload: for WordPress watch 4K random read and single-core, for video watch bandwidth and sequential read, for API-heavy sites watch memory bandwidth.
5. Don't just trust peak numbers. A great score doesn't mean stability during peak hours — compare business-hours results against off-hours results; a big gap usually means overselling or bandwidth throttling.