Choosing a VPS host means trusting someone else's hardware with your production workloads. Marketing promises don't tell you whether disk I/O will choke during backups or whether the network can handle a traffic spike. I tested nine providers head-to-head with real benchmark tools, then ran the same workloads for seventy-two hours to see which ones stayed fast.
This isn't a feature comparison. It's about raw performance: uptime, disk throughput, network speed, and CPU consistency under sustained load.
What I tested and why it matters
Each provider got a fresh 2-vCPU, 4GB RAM instance running Ubuntu 24.04 LTS. I picked the closest data center to US East for network parity and avoided promotional trials that might have different hardware.
Four metrics matter for real hosting work:
- Uptime and stability — a provider that reboots your instance for maintenance without notice costs you incident reports and 3 AM pages.
- Disk I/O throughput — slow random writes kill database performance and turn a five-minute backup into twenty.
- Network throughput and latency — affects everything from API responses to asset delivery.
- CPU consistency — noisy neighbors and oversubscription show up as variance in repeated benchmark runs.
I ran fio for disk tests, iperf3 for network, sysbench for CPU, and ab for HTTP load simulation. Each test ran five times; I kept the median to filter outliers.
Disk I/O: random writes separate the field
Sequential read speed looks good on spec sheets but doesn't reflect real application patterns. Databases and busy web servers do thousands of small random writes per second.
I tested random 4K writes with fio at queue depth 32:
fio --name=random-write --ioengine=libaio --iodepth=32 \
--rw=randwrite --bs=4k --direct=1 --size=2G \
--numjobs=4 --runtime=60 --group_reporting
The spread was wider than expected. Top-tier providers hit 15,000–25,000 IOPS on random writes. Mid-range hosts delivered 8,000–12,000 IOPS. Two budget providers consistently tested below 3,000 IOPS, which will bottleneck any write-heavy application.
One provider delivered 28,000 IOPS on the first run, then dropped to 9,000 on subsequent tests. That's a throttling policy kicking in — fine for bursty workloads, but a problem if you run continuous database writes.
Sequential read and write speeds were less variable. Most providers delivered 400–600 MB/s sequential reads and 250–400 MB/s sequential writes, adequate for log streaming and large file transfers.
Network throughput: most deliver, latency varies
I used iperf3 to measure TCP throughput to a reference server in the same region:
iperf3 -c reference-server.example.com -t 30 -P 4
Almost everyone delivered near-line-rate performance: 900 Mbps to 1 Gbps on 1 Gbps ports, 1.8–2 Gbps on instances with 2 Gbps allocation. Network throughput alone doesn't separate providers anymore.
Latency did. Ping times to a regional target ranged from 0.8 ms to 4.2 ms. Under sustained load with ab hitting an nginx instance at 500 req/sec, some providers showed latency spikes to 40+ ms while others stayed flat under 2 ms. That variance points to network congestion or oversubscribed uplinks.
One provider's network was fast but unstable — three brief disconnects during the 72-hour test, each lasting under thirty seconds. Long enough to drop active SSH sessions and trigger monitoring alerts.
CPU performance: watch for steal time
Raw CPU benchmarks with sysbench showed expected results; modern Xeon and EPYC processors are fast. What matters more is consistency.
I ran sysbench cpu --threads=2 --time=60 every hour for three days and calculated the standard deviation of execution time. Low variance means predictable performance; high variance indicates CPU contention or steal.
Three providers showed steal time above 5% during peak hours, visible in top as %st. That's the hypervisor taking CPU cycles away to give to other tenants. If your application is CPU-sensitive — video encoding, image processing, compiling large codebases — steal time will hurt.
The best performers kept steal time under 1% even during business hours. One provider never showed measurable steal across the entire test period, which suggests either good capacity planning or less aggressive oversubscription.
So what about uptime?
All nine providers stayed online for the 72-hour test window. No unplanned reboots, no instance freezes. That's the minimum bar.
What differed was maintenance transparency. Two providers emailed 48-hour advance notice for scheduled maintenance windows. Three gave 7-day notice. One performed a reboot with only 6 hours of warning, which wouldn't give you time to schedule around it in a busy week.
Check the provider's status page history before committing. Look for how often they post incidents and whether they explain root causes. Frequent "investigating connectivity issues" posts without details suggest operational immaturity.
Real-world web hosting load
Benchmarks are useful but synthetic. I deployed a standard WordPress installation with WooCommerce, 5,000 products, and a mid-size media library, then hit it with ab at 100 concurrent connections for 10 minutes:
ab -n 50000 -c 100 https://testsite.example.com/
Providers with weak disk I/O showed page load times climbing from 400 ms to over 2 seconds as the object cache filled and MySQL wrote to disk. Strong I/O performers stayed under 600 ms throughout.
Memory pressure was consistent across providers at this scale — 4GB was enough for PHP-FPM, MySQL, Redis, and nginx without swapping. Disk and CPU mattered more than RAM for WordPress under load.
Storage type matters more than marketing
Every provider advertises "SSD storage" but that covers NVMe, SATA SSD, and SAN-backed storage with SSD caching. The differences show up in IOPS, not capacity.
NVMe-backed instances delivered 3–5× better random write performance than SATA SSD instances at similar price points. If your workload is database-heavy or runs frequent backups, pay for NVMe.
Two providers offered "high-frequency" CPU upgrades for 20–30% more per month. In testing, those instances showed 15–20% better CPU performance but identical disk and network numbers. Worth it for compute-bound tasks, not worth it for web hosting.
Managed vs. unmanaged performance
Managed VPS plans include monitoring agents, automatic updates, and often a control panel. I tested one provider's managed and unmanaged tiers on identical hardware.
The managed instance used 8–10% more RAM at idle and showed slightly higher CPU baseline due to the monitoring daemon. Disk I/O was identical. If you need the management features, the performance cost is negligible. If you're comfortable with the command line, unmanaged saves money without sacrificing speed.
Geographic differences in the same provider
One provider operates 14 data centers globally. I spun up instances in US East, US West, and EU to see if performance varied by region.
US East and EU showed nearly identical results across all benchmarks. US West had 20% lower disk I/O and occasionally higher steal time, suggesting older hardware or higher tenant density. Regional variation exists even within a single provider — test the data center you'll actually use.
What surprised me
Price didn't correlate with performance as tightly as expected. The second-most-expensive provider finished fifth in overall performance. A mid-priced option delivered top-three results across every test.
Provider reputation didn't predict results either. One well-known brand with strong community presence showed mediocre I/O and frequent latency spikes. A lesser-known provider I tested on a recommendation outperformed hosts twice its price.
Block storage add-ons varied wildly in speed. Some were faster than the instance's root disk; others were slower than spinning rust. If you need extra volumes, test them before moving production data.
Run your own tests first
Benchmark results age quickly. Providers upgrade hardware, change network topology, and adjust resource allocation policies.
Most hosts offer hourly billing or money-back guarantees. Spin up an instance, run fio and sysbench for 24 hours, and test your actual workload before committing to annual contracts. Check for steal time during your region's peak hours, not at 3 AM.
Performance matters, but so does support quality, backup reliability, and whether the provider will answer a ticket on Sunday night. Use benchmarks as one signal among several, and weight them based on your application's actual bottlenecks.