I ran the same set of synthetic and real-world benchmarks across eight VPS providers to answer one question: which actually delivers the speed it promises? Marketing pages are full of claims about NVMe drives and premium network uplinks, but the only way to know is to spin up instances and measure.
This comparison uses standard benchmark tools—fio for disk I/O, iperf3 for network throughput, sysbench for CPU—on identically sized instances. All tests were run on 2 vCPU, 4 GB RAM plans in US data centers during the same week to keep variables consistent.
Test methodology
Each provider was tested on a fresh Ubuntu 22.04 instance with minimal software installed. I let each VM settle for 30 minutes after boot before running benchmarks to avoid launch-time anomalies.
Disk I/O tests used fio with a 4 GB file, mixed random read/write operations at queue depth 32. Network tests ran iperf3 against three geographically distributed public servers and averaged the results. CPU tests used sysbench to calculate prime numbers up to 20,000 across all cores. Each test ran three times and I took the median result.
No provider was told they were being tested. These are production instances billed at standard rates.
Disk I/O results
Disk performance matters most for database-heavy workloads and any application that writes logs or caches aggressively. The gap between NVMe and older SSD storage is real, but so is the gap between shared and dedicated NVMe.
The top performer hit around 400 MB/s on sequential reads and held above 200 MB/s on random writes. Mid-pack providers clustered between 150-250 MB/s sequential and 80-120 MB/s random. The slowest showed clear signs of oversubscription—performance dropped by half when I ran tests during what I assume was their peak load window.
One provider advertised NVMe but delivered speeds closer to SATA SSD. Check the IOPS, not just the drive type.
Here's the fio command I used for random mixed workload:
fio --name=randmix --ioengine=libaio --iodepth=32 --rw=randrw \
--rwmixread=70 --bs=4k --direct=1 --size=4G --numjobs=4 \
--runtime=60 --group_reporting
If your application writes frequently—WordPress with object caching, a busy API server, MySQL with InnoDB—prioritize sustained random write performance over peak sequential reads.
Network throughput
Network speed determines how fast you can serve assets, handle API traffic, and replicate data between servers. Most providers claim 1 Gbps or higher, but actual throughput depends on peering, route quality, and how much bandwidth they oversubscribe.
The best performer sustained 850+ Mbps to all three test endpoints. That's close enough to line rate. Mid-tier results ranged from 400-600 Mbps, still adequate for most workloads but noticeably slower under load. One provider barely cracked 200 Mbps to distant endpoints and showed packet loss during evening hours.
Geography matters. A provider with great bandwidth to North America might route Asian traffic through suboptimal paths. If your users are global, test from multiple regions.
I also checked latency to major public DNS resolvers. The spread was 8ms to 45ms, which sounds small but compounds when your application makes dozens of external API calls per page load.
CPU performance under load
Most VPS providers use CPU oversubscription—selling more vCPUs than physical cores. That's fine until neighboring tenants start hammering their instances. The question is how much performance degrades under contention.
I ran sysbench CPU tests during off-peak and peak hours. The best providers showed less than 5% variance between time windows. Others dropped by 20-30% during evening hours, which suggests heavy oversubscription or poor resource isolation.
One provider consistently delivered stable performance regardless of time of day. That stability matters more than peak numbers if you're running production workloads.
Here's the sysbench command for multi-threaded CPU testing:
sysbench cpu --cpu-max-prime=20000 --threads=2 run
Applications with bursty CPU patterns—build servers, video encoding, batch processing—will notice performance drops on oversold hosts. If your workload is CPU-bound, test during your expected traffic peaks before committing.
What about steal time?
Steal time measures how long your VM waited for CPU because the hypervisor gave cycles to another guest. It's the clearest indicator of oversubscription. I monitored %steal in top during all tests.
The best providers showed 0-2% steal even under load. Mid-tier averaged 5-8%. The worst spiked above 15% during peak hours, which means your application sits idle while waiting for CPU. That kills database query performance and API response times.
Check steal time on your own VPS:
top
# Look at the %st column in the CPU summary line
# Anything consistently above 5% is a red flag
High steal time isn't always the provider's fault—noisy neighbors can spike it temporarily. But consistent high steal means the host is oversold.
Real-world WordPress benchmark
Synthetic benchmarks are useful, but I also wanted to test a real workload. I installed WordPress with WooCommerce, imported a standard demo store with 5,000 products, enabled Redis object caching, and hit the front page with wrk to simulate 50 concurrent users.
The results correlated strongly with disk I/O performance. Providers with fast random writes handled 80-120 requests per second with sub-200ms response times. Slower disk I/O providers dropped to 40-60 req/s with response times climbing above 400ms under load.
Network throughput mattered less for this test because assets were small and served from the same server. But in a real setup with a CDN pulling from origin, network speed would become the bottleneck.
So which provider won?
The top three were separated by small margins. One excelled at disk I/O, another at network consistency, a third at CPU stability. Your best choice depends on your workload profile.
For database-heavy applications, pick the provider with the best sustained random write performance and lowest steal time. For media serving or API endpoints with global users, network throughput and routing quality matter more. For batch processing or build servers, stable CPU performance across time windows is critical.
The bottom two providers were significantly worse across all metrics. Both showed signs of heavy oversubscription—high steal time, inconsistent network throughput, disk I/O that varied wildly by time of day. Avoid them unless price is your only consideration.
Performance vs. price
The fastest provider also cost 40% more than the median. The slowest was cheapest but delivered maybe 60% of the performance. The best value sat in the middle—good performance at a reasonable price, with low variance under load.
In support tickets I handled, the usual culprit behind mysterious slowdowns was switching to a cheaper VPS without testing. You can't assume performance scales linearly with price. A $10/month VPS from a premium provider might outperform a $15/month plan from an oversold host.
Test before you migrate production workloads. Spin up an instance, run your own benchmarks, monitor for a few days. If performance holds steady during your peak traffic hours, you've found a good fit.
Monitoring your own VPS performance
Don't rely on a one-time benchmark. Performance can degrade as providers add customers to the same physical hardware. Set up basic monitoring:
# Install iotop for disk I/O monitoring
sudo apt install iotop
# Install iftop for network bandwidth
sudo apt install iftop
# Check steal time and load average
vmstat 1 10
If you see disk I/O wait time climbing, steal time increasing, or network throughput dropping week over week, open a ticket. Sometimes you just got unlucky with noisy neighbors and support can migrate you to a different host.
Testing your own provider
You can run the same tests I did. Install the benchmark tools:
sudo apt update
sudo apt install fio sysbench iperf3
Run a quick disk I/O test:
fio --name=test --ioengine=libaio --iodepth=32 --rw=randrw \
--bs=4k --direct=1 --size=1G --runtime=30 --group_reporting
And a CPU benchmark:
sysbench cpu --cpu-max-prime=10000 --threads=$(nproc) run
Compare your numbers against your provider's marketing claims and against results from other users. If you're way below what others report, something's wrong.
Do all providers in a region perform the same?
No. Even within the same data center, performance varies by which physical hardware hosts your VM and how much the provider oversubscribes resources.
Can I trust provider-published benchmarks?
Rarely. Providers test under ideal conditions on empty hosts. Real-world performance once the host fills up is what matters. Run your own tests or find third-party benchmarks from multiple time periods.
Does upgrading to a larger plan improve performance?
Usually, but not always. Larger plans often get dedicated CPU cores or better disk I/O allocation. But if the provider oversells aggressively, even large plans suffer. Check steal time and IOPS variance first.
How often should I re-benchmark?
Every few months or whenever you notice performance changes. Providers add customers, shift workloads between hosts, and upgrade hardware. What performed well six months ago might not today.
What to measure before choosing
Run disk I/O, CPU, and network tests during your expected peak hours. Monitor steal time for at least 48 hours. Check that performance stays consistent across different times of day. Compare results against other users' reports to make sure you're not on an overloaded host.
If the numbers are stable and meet your workload requirements, you've found a solid provider. If they fluctuate wildly or show high steal time from day one, keep looking.