A VPS spec sheet lists cores, RAM, and SSD size \u2014 but none of those numbers tell you how the server actually performs under your workload. Two $20 plans from different providers can differ by 3x in CPU throughput and 10x in disk latency, because hypervisor configuration, neighbor contention, and storage architecture are invisible in the marketing materials. Benchmarking is the only way to find out what you’re really paying for. This guide shows you how to test CPU, disk, and network with the three tools that matter \u2014 sysbench, fio, and iperf3 \u2014 and how to interpret the results.<\/p>\n\n\n\n
Install the tools and make sure the server is otherwise idle. A benchmark running next to a production web server tells you nothing about the machine’s ceiling:<\/p>\n\n\n\n
sudo apt update && sudo apt install -y sysbench fio iperf3\n\n# Confirm you're on the latest kernel (needed for modern NVMe behavior)\nuname -r\n\n# Check current load \u2014 should be near zero before you start\nuptime\nnproc<\/code><\/pre>\n\n\n\nRecord nproc<\/code> and your RAM size \u2014 you’ll need them to interpret the results. Run every test three times and take the median; a single run on a shared host can be skewed by a noisy neighbor.<\/p>\n\n\n\nCPU: sysbench Prime Number Test<\/h2>\n\n\n\n
sysbench’s CPU test computes prime numbers, which exercises integer arithmetic and the scheduler without touching disk or network. Run it single-threaded first to measure raw per-core speed, then multithreaded to check scaling:<\/p>\n\n\n\n
# Single-thread: per-core speed (events\/sec)\nsysbench cpu --threads=1 --time=30 --cpu-max-prime=20000 run\n\n# Multithread: scale with your vCPU count\nsysbench cpu --threads=$(nproc) --time=30 --cpu-max-prime=20000 run<\/code><\/pre>\n\n\n\nWhat to look for:<\/strong> the single-thread events per second<\/code> tells you the CPU generation \u2014 modern EPYC\/Xeon vCPUs typically score 1500\u20132500 events\/sec on this workload, while older or heavily throttled vCPUs fall under 1000. Compare the multithreaded result to the single-thread result: with 4 vCPUs you should see roughly 3.5\u20134x. If the scaling factor is far below the core count, you’re likely hitting CPU steal or an oversubscribed host \u2014 check %st<\/code> in top<\/code> during the run.<\/p>\n\n\n\nDisk: fio Random Reads and Writes<\/h2>\n\n\n\n
fio is the industry-standard storage benchmark. The two tests that matter for typical VPS workloads are 4 KiB random reads (database\/application files) and sequential writes (logs, backups). Use --direct=1<\/code> to bypass the page cache so you measure the storage, not RAM:<\/p>\n\n\n\n# 4 KiB random reads \u2014 the database pattern\nfio --name=randread --ioengine=libaio --iodepth=32 --rw=randread \\\n --bs=4k --size=1G --numjobs=4 --runtime=30 --direct=1 \\\n --group_reporting\n\n# Sequential writes \u2014 the logging pattern\nfio --name=seqwrite --ioengine=libaio --iodepth=16 --rw=write \\\n --bs=1M --size=1G --runtime=30 --direct=1 --group_reporting<\/code><\/pre>\n\n\n\nWhat to look for:<\/strong> focus on IOPS<\/code> for random reads and BW<\/code> (bandwidth) for sequential writes. A shared-SSD VPS typically delivers 2,000\u201310,000 random-read IOPS; NVMe-backed plans reach 20,000\u2013100,000+. The number that matters even more is latency (usec)<\/code> \u2014 the p99 column. Sub-millisecond p99 on random reads is excellent; sustained p99 above 5 ms means the storage tier is throttled or contended.<\/p>\n\n\n\nNetwork: iperf3 Throughput and Latency<\/h2>\n\n\n\n
iperf3 measures real throughput between two endpoints, which captures the actual path your traffic takes. You need a second machine \u2014 a desktop, another VPS, or a free instance at a cloud provider:<\/p>\n\n\n\n
# On the second machine (server side):\niperf3 -s\n\n# On your VPS (client side), 30 seconds, 8 parallel streams:\niperf3 -c SERVER_IP -t 30 -P 8\n\n# Reverse direction (uploads from the VPS):\niperf3 -c SERVER_IP -t 30 -P 8 -R\n\n# Latency check from the VPS (10 packets):\nping -c 10 SERVER_IP<\/code><\/pre>\n\n\n\nWhat to look for:<\/strong> a VPS with a 1 Gbps port should push 800\u2013950 Mbps in both directions; 10 Gbps plans should clear 5+ Gbps with parallel streams. If throughput is symmetric but low (under 300 Mbps), check your plan’s port speed and the provider’s transit quality. Pair the throughput test with ping<\/code> latency \u2014 sub-10 ms to a nearby city is good; 50+ ms to the provider’s own datacenter region suggests routing problems.<\/p>\n\n\n\nPutting It Together: The Three-Number Scorecard<\/h2>\n\n\n\n
After the tests, you should have three headline numbers: single-thread CPU events\/sec, random-read IOPS, and bidirectional throughput. Save them with the date and provider in a file \u2014 this becomes your baseline for regression testing and your ammunition for comparing plans when renewal time comes:<\/p>\n\n\n\n
cat <<'EOF' > ~\/vps-benchmark-$(date +%F).txt\nProvider: (name)\nPlan: (specs)\nCPU events\/s: (single \/ multi)\n4k randread: (IOPS \/ p99 latency)\nseq write: (MB\/s)\niperf3: (Mbps down \/ up)\nEOF<\/code><\/pre>\n\n\n\nWhat Your Numbers Mean for Provider Choice<\/h2>\n\n\n\n
Benchmarks exist to be compared. If your current VPS shows 800 single-thread events\/sec and 3,000 random-read IOPS while a competitor at the same price shows 2,000 and 25,000, the performance gap is not your configuration \u2014 it’s the hardware tier and overcommit policy. Before you switch on price alone, compare VPS providers on our comparison table<\/a> to see CPU model, storage type, and port speed side by side, then run the same three tests on any candidate before committing.<\/p>\n\n\n\nIf you want a provider that consistently benchmarks well for the price, InterServer’s VPS plans<\/a> use modern EPYC hardware with NVMe storage \u2014 worth adding to your test list. And if benchmarking sounds like work you’d rather skip, a managed platform like Cloudways<\/a> pre-selects and maintains high-performing infrastructure for you.<\/p>\n\n\n\n