Pre-Purchase Benchmarking for a Budget VPS: The 30-Minute Test Sequence

Most people choose a budget VPS by comparing a table of numbers, then discover the real product in production three weeks later when a nightly backup saturates the disk and the site starts returning 502s. The answer is not to read more reviews — it is to spend 30 minutes measuring the candidate instance in the exact conditions your workload creates. This is a fixed, repeatable sequence: ten tests, in order, from cheapest to most revealing, with thresholds that tell you to walk away.

The sequence assumes an hourly or money-back trial, which nearly every budget provider offers. Provision the smallest plan in the tier you are considering, in the region you will actually run in — a plan benchmarked in Frankfurt says nothing about the same plan in Los Angeles. If you are still narrowing candidates, the provider comparison tables list entry-tier CPU, RAM and storage side by side before you spend anything.

Minutes 0-3: Establish What You Actually Bought

Before benchmarking anything, confirm the product class. systemd-detect-virt returning kvm means you have a real kernel and can load modules; returning lxc or openvz 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.

Finally, record free -m 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 — you will need the baseline when you repeat the run at peak hour.

Minutes 3-10: CPU Throughput and Steal

Run sysbench cpu --threads=$(nproc) --time=60 run 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 and average the %steal 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.

Then run the same benchmark single-threaded (--threads=1). 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.

Minutes 10-18: Disk, the Real Differentiator

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 — a distinction that matters because throttles punish sustained workloads like databases and backup jobs while leaving interactive sites untouched.

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.

Minutes 18-23: Network Ceiling and Path Quality

Port speed is a ceiling, not a promise. Run iperf3 -c ping.online.net -P 4 -t 30; 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 and look for packet loss — 2% at a single hop is a peering problem no extra CPU will fix.

Latency 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.

Minutes 23-27: The Peak-Hour Repeat

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 — under 20% degradation means sanely packed; a 2-3x drop means heavy neighbours.

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.

Minutes 27-30: Operation, Not Benchmark

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 — those are the 2 a.m. operations.

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 — it changes the plan’s effective price far more than a dollar of monthly savings.

The Decision Table

Test	Budget-acceptable	Walk away
Steal under load	<5%	>15%
Sustained 4k randwrite	>8,000 IOPS, p99 <5 ms	<1,000 IOPS or collapsing p99
Sequential write	>400 MB/s	<150 MB/s
Port speed vs claim	Within 15%	Claims 1 Gbps, delivers 100 Mbps
Peak vs off-peak	<20% degradation	>2x degradation
Snapshot restore	<5 min	>15 min
Support first response	<60 min	>6 h

Two or more walk-away results mean the plan is expensive with a low sticker price — you pay the difference in ops time. One marginal result is survivable if your workload is insensitive to it: a blog does not care about 2,000 IOPS, a CI runner does not care about single-query p99. Match failures to workload, not aggregate score.

After You Commit

Re-run the suite 30 days in. Providers migrate instances between physical hosts during maintenance, and the node you benchmarked may not be the node you occupy by month two. Keeping day-one baselines turns “it feels slow lately” into a measurable regression you can take to support with evidence.

If you want a starting point whose specs are described in the terms this sequence measures, the VPS plans on the main site list the allocation details worth checking first. Thirty minutes of disciplined testing will save you far more than the same time spent reading reviews, and it is the only method that reflects the host you will actually be running on.