Benchmark scores look scientific, but most of them are entertainment. A multi-core CPU number tells you almost nothing about whether your web application feels fast, and a sequential disk throughput figure says even less. What predicts real-world behavior is a small set of tests run the way your workload actually touches the hardware: 4k random I\/O at low queue depth, single-threaded CPU latency, and network tests in both directions. This guide explains what each benchmark measures, the profiles that match real workloads, and a 15-minute protocol you can run before committing to a provider.<\/p>\n\n\n\n
The fix is simple: run the same tests yourself, several times, and treat variance as a first-class result.<\/p>\n\n\n\n
# single-threaded latency (what most web requests see)\nsysbench cpu --threads=1 --cpu-max-prime=20000 run\n# all-thread throughput\nsysbench cpu --threads=$(nproc) --cpu-max-prime=20000 run\n# watch steal during the run\nmpstat -P ALL 1<\/code><\/pre>\n\n\n\nRun both sysbench variants three times. If the single-thread score swings more than ~10% between runs while steal<\/code> climbs in mpstat, the plan is oversubscribed and your latency will be unpredictable at peak hours.<\/p>\n\n\n\nDisk: match the queue depth to your workload<\/h2>\n\n\n\n
fio is the standard tool. Use profiles that mirror what your applications actually do:<\/p>\n\n\n\nProfile<\/th> rw \/ bs \/ iodepth<\/th> What it predicts<\/th><\/tr><\/thead> Database-style<\/td> randwrite, 4k, iodepth=1<\/td> Transaction commit latency<\/td><\/tr> File serving<\/td> randread, 16k, iodepth=8<\/td> Mixed static\/dynamic reads<\/td><\/tr> Sequential<\/td> write, 128k, iodepth=8<\/td> Backups and large transfers<\/td><\/tr> fsync-heavy<\/td> write, 4k, sync=1<\/td> Database durability (WAL fsyncs)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nfio --name=db4k --rw=randwrite --bs=4k --iodepth=1 --size=256M \\\n --ioengine=libaio --direct=1 --runtime=60 --time_based<\/code><\/pre>\n\n\n\nFor a database or dynamic web app, the 4k random-write latency at iodepth 1 (with sync=1<\/code> if you use InnoDB or PostgreSQL) matters far more than sequential throughput. If that latency jumps between runs, the storage tier is shared and noisy \u2014 a red flag for production.<\/p>\n\n\n\nNetwork: both directions, both protocols<\/h2>\n\n\n\n
Test to a host in the region your users actually live in, and always measure the return path:<\/p>\n\n\n\n
iperf3 -c target-host -t 60 # upload\niperf3 -c target-host -t 60 -R # download (reverse)\nping -c 100 target-host # latency + packet loss\nmtr -rwzb target-host # path and per-hop loss<\/code><\/pre>\n\n\n\nCloud providers often route upload and download asymmetrically, so a single-direction test can miss a congested return path. Also remember that traffic between two VPSes of the same provider stays inside the datacenter and looks much better than the public path your users traverse.<\/p>\n\n\n\n
Memory: bandwidth, latency, and swap behavior<\/h2>\n\n\n\n
Memory is rarely the component people benchmark, yet it decides how a small VPS behaves under pressure. Measure bandwidth with sysbench memory --memory-block-size=1M --memory-total-size=10G run<\/code> and confirm with mbw -b 4096<\/code>. More informative than raw numbers is behavior under pressure: fill RAM with a few stress-ng --vm<\/code> workers, watch the si<\/code>\/so<\/code> columns in vmstat<\/code>, and measure your application’s latency while the box is swapping. A plan that thrashes swap instead of recovering quietly shows up immediately as request latency \u2014 and no CPU score will ever warn you about it.<\/p>\n\n\n\nA 15-minute repeatable protocol<\/h2>\n\n\n\n- Record provider, plan, region, and timestamp.<\/li>
- Run sysbench CPU: 1 thread and all threads, three times each.<\/li>
- Run fio: 4k randwrite (iodepth 1), 16k randread, 128k sequential \u2014 three times each.<\/li>
- Run iperf3 in both directions to a host in your target region.<\/li>
- Ping 100 packets and run mtr to check loss and path.<\/li>
- Note steal % from mpstat during every CPU and fio run.<\/li>
- Repeat the whole set at a different hour the next day.<\/li><\/ol>\n\n\n\n
The variance between the two sessions is the real finding: stable numbers across hours suggest a quiet neighbourhood; big swings mean you are sharing noisy hardware. If you are comparing plans side by side, our VPS comparison table<\/a> lists providers worth putting through this protocol.<\/p>\n\n\n\nThe number that actually matters: your workload<\/h2>\n\n\n\n
No synthetic test replaces end-to-end measurement of your own stack. Deploy the application, hit it with wrk<\/code> or siege<\/code> at realistic concurrency, and record time-to-first-byte and requests per second. A benchmark that does not include your code is entertainment; the combination of synthetic profiles plus a real workload test is how you choose VPS hosting you can rely on<\/a>.<\/p>\n\n\n\n