provider comparison tables<\/a> list entry-tier CPU, RAM and storage side by side before you spend anything.<\/p>\n\n\n\nMinutes 0-3: Establish What You Actually Bought<\/h2>\n\n\n\n
Before benchmarking anything, confirm the product class. systemd-detect-virt<\/code> returning kvm<\/code> means you have a real kernel and can load modules; returning lxc<\/code> or openvz<\/code> means you are a cgroup slice on a shared kernel, which changes how every later measurement should be read. Then capture the CPU model and the clock ceiling, because a “2 vCPU” plan on a 2017 Xeon at 2.2 GHz and one on an EPYC at 3.7 GHz are not the same product at the same price.<\/p>\n\n\n\nFinally, record free -m<\/code> and compare MemAvailable against the advertised figure. A 2 GB plan that reports 1.7 GB available on a freshly booted minimal image is honest; one reporting 1.4 GB has ballooning or a hypervisor reserving memory you are paying for. Write all of this down before you touch a benchmark \u2014 you will need the baseline when you repeat the run at peak hour.<\/p>\n\n\n\nMinutes 3-10: CPU Throughput and Steal<\/h2>\n\n\n\n
Run sysbench cpu --threads=$(nproc) --time=60 run<\/code> and note events per second, then divide by vCPU count for a per-core figure you can compare across plan sizes. Simultaneously sample mpstat -P ALL 1 60<\/code> and average the %steal<\/code> column. Under full saturation, steal above 5% means you are sharing a contended core; above 15% means the plan is essentially a time-share and should be rejected for anything latency-sensitive.<\/p>\n\n\n\nThen run the same benchmark single-threaded (--threads=1<\/code>). A 2 vCPU plan scoring 1.3x the single-thread result rather than ~1.9x is oversubscribed at the hypervisor level, whatever the order page said.<\/p>\n\n\n\nMinutes 10-18: Disk, the Real Differentiator<\/h2>\n\n\n\n
Storage is where budget plans diverge by an order of magnitude, and where short benchmarks lie hardest. Run a 60-second random write at iodepth 32, not a 5-second burst, and read three numbers: IOPS over the whole run, p99 completion latency, and the IOPS in the final 20 seconds. If the last third is a fraction of the first third, you are hitting a burst-credit or token-bucket throttle rather than a slow device \u2014 a distinction that matters because throttles punish sustained workloads like databases and backup jobs while leaving interactive sites untouched.<\/p>\n\n\n\n
Repeat with a sequential write of at least 1 GB. Budget NVMe that sustains 400-800 MB\/s sequential and 8,000+ IOPS of 4k random write with p99 under 5 ms is a good deal; SATA-backed plans typically land at 150-250 MB\/s and 2,000-4,000 IOPS. Anything that falls below 1,000 sustained IOPS will make even a modest MySQL instance feel broken under concurrent load.<\/p>\n\n\n\n
Minutes 18-23: Network Ceiling and Path Quality<\/h2>\n\n\n\n
Port speed is a ceiling, not a promise. Run iperf3 -c ping.online.net -P 4 -t 30<\/code>; a “1 Gbps” plan that peaks at 95 Mbps is a 100 Mbps port with better marketing. Then run mtr -rwzbc 100 1.1.1.1<\/code> and look for packet loss \u2014 2% at a single hop is a peering problem no extra CPU will fix.<\/p>\n\n\n\nLatency to your actual user base matters more than raw bandwidth for most small sites. Ping the nearest IXP to your users and compare with a competitor’s trial instance in the same city. A 40 ms RTT difference is worth more than doubling port speed, and it is invisible on any spec sheet.<\/p>\n\n\n\n
Minutes 23-27: The Peak-Hour Repeat<\/h2>\n\n\n\n
Every number so far was taken when the host was probably quiet. Re-run the CPU and disk suite at 8-9 p.m. in the provider’s datacentre region, when neighbours are busy. The most predictive metric on a budget VPS is peak-to-off-peak ratio \u2014 under 20% degradation means sanely packed; a 2-3x drop means heavy neighbours.<\/p>\n\n\n\n
Record both runs in the same sheet. If you only have an hour of trial time, spend it here rather than repeating the quiet-hour tests; a plan that is merely average at 3 a.m. and stable at 8 p.m. is a better purchase than one that is brilliant at 3 a.m. and unusable at 8 p.m.<\/p>\n\n\n\n
Minutes 27-30: Operation, Not Benchmark<\/h2>\n\n\n\n
Benchmark the control plane last, because it is what you touch during an incident. Time a snapshot, then a restore into a new instance. A 90-second snapshot with a four-minute restore is fine; five minutes with a twenty-minute restore is a liability. Time a rebuild and resize too \u2014 those are the 2 a.m. operations.<\/p>\n\n\n\n
Then break something small and open a ticket to measure first response. Fifteen minutes at an odd hour is a good result for a budget provider; six hours is a business risk. Log it beside the benchmarks \u2014 it changes the plan’s effective price far more than a dollar of monthly savings.<\/p>\n\n\n\n