I spun up identical VPS instances across nine providers and ran the same battery of tests on each: boot time from API call to SSH access, network throughput using iperf3 against multiple endpoints, and disk I/O with fio running mixed read/write patterns. The goal was simple—find out which provider actually delivers the fastest experience for the three workloads I see most often in support tickets.
No marketing claims. Just SSH, a stopwatch, and a spreadsheet.
The test setup
Every provider got the same configuration request: 2 vCPU, 4 GB RAM, 80 GB SSD, running Ubuntu 22.04 LTS. I picked the closest data center to US East for each provider to keep latency comparable. Each test ran three times and I averaged the results.
Boot time started the moment I fired the API create call and ended when I could complete an SSH handshake. Network tests hit both the provider's own speed test endpoints and three external iperf3 servers I control in different regions. Disk I/O used fio with a 4k random read/write mix at queue depth 32, the pattern that mimics database workloads.
I didn't test during known sale events or maintenance windows. All tests happened between 0200 and 0600 UTC on weekdays to avoid peak traffic.
Boot time matters more than you think
A fast boot means the hypervisor isn't oversubscribed and the storage layer can handle IOPS spikes. Slow boots often predict slow disk performance under load.
The fastest provider went from API call to SSH prompt in 28 seconds. The slowest took nearly four minutes. That 28-second provider also topped the disk I/O charts, which isn't a coincidence—both metrics reflect how much physical resource contention exists on the host node.
In the middle of the pack, most providers clustered around 45 to 75 seconds. Anything under a minute is fine for production workloads. Over two minutes and you're looking at either oversubscription or slow network-attached storage.
Network throughput: regional differences were huge
I tested both inbound and outbound throughput to my own iperf3 servers in Virginia, Frankfurt, and Singapore. Most providers advertised "up to 1 Gbps" but real-world numbers varied wildly.
To a Virginia endpoint from a US East VPS, the top three providers all delivered 850+ Mbps in both directions. The bottom two struggled to hit 300 Mbps outbound, even though inbound was fine—classic oversubscribed uplink.
Cross-region told a different story. Testing from US East to Frankfurt, one provider that dominated domestic tests dropped to 180 Mbps because their peering to Europe is terrible. Another mid-pack domestic provider jumped to the top internationally with consistent 600+ Mbps paths.
If you serve a global audience, test cross-region yourself before committing. The fastest domestic provider isn't always the fastest internationally.
# Quick network test to your own server
sudo apt update && sudo apt install -y iperf3
iperf3 -c your-server.example.com -t 30 -P 4
Run that both directions and compare. Four parallel streams surfaces bandwidth shaping issues that single-stream tests miss.
Disk I/O: NVMe isn't always NVMe
Every provider claimed SSD or NVMe storage, but measured performance ranged from 15k IOPS to over 90k IOPS on random 4k reads. That's a six-times difference.
The highest IOPS came from providers using local NVMe drives physically attached to the hypervisor host. Mid-range numbers usually meant network-attached SSD arrays with good controllers. The slowest results pointed to either SATA SSDs or severely oversubscribed NVMe pools.
For database-heavy workloads like WordPress with WooCommerce or Magento, that IOPS gap translates directly to page load time. A MySQL instance on 90k IOPS hardware will feel snappy under load. The same database on 15k IOPS will start queueing queries during traffic spikes.
Write performance varied less than read performance, but write latency told the real story. The best providers showed sub-millisecond write latency even under mixed load. The worst spiked to 15-20ms, which causes noticeable application pauses.
# Test disk I/O yourself
sudo apt install -y fio
fio --name=randreadwrite --ioengine=libaio --iodepth=32 --rw=randrw \
--bs=4k --direct=1 --size=2G --numjobs=4 --runtime=60 --group_reporting
Watch the IOPS numbers and the latency percentiles. If p99 latency exceeds 10ms, your database will stall under load.
Which provider won each category?
Boot time and disk I/O had the same winner—a provider running local NVMe on recent AMD EPYC hardware with what looks like conservative oversubscription ratios. Their smallest VPS booted in under 30 seconds and delivered 88k read IOPS.
Network speed domestically went to a different provider with excellent peering to major US internet exchanges. They hit 920 Mbps to my Virginia test server consistently.
International network performance crowned a third winner, one that's invested heavily in their own backbone between regions. Their US to Europe path stayed above 650 Mbps even during European business hours.
No single provider won everything, which is why knowing your workload matters. Are you running a latency-sensitive API that needs fast local disk? Pick the IOPS winner. Serving video or large downloads globally? The international network winner makes more sense. Regional web app with database-backed content? The domestic network champion will serve you well.
What the numbers didn't show
Benchmarks can't measure everything. I didn't test noisy neighbor resilience—whether other tenants on the same physical host impact your performance. That requires weeks of monitoring, not a one-time test.
Support quality doesn't show up in iperf3 output either. The fastest VPS is useless if you can't get kernel panic logs from the console or if the provider takes four hours to respond to a network outage.
Uptime and network stability matter more than peak throughput for production workloads. A provider that delivers 700 Mbps 99.9% of the time beats one that hits 900 Mbps but drops to 50 Mbps during traffic spikes.
Testing methodology details
Boot time measurement started with a Unix timestamp captured immediately before the API create call and ended with the timestamp from a successful SSH connection. I used the provider's API where available and their web console otherwise, which slightly disadvantaged providers with slower web interfaces.
Network tests used iperf3 in TCP mode with four parallel streams, 30-second duration, repeated three times with five-minute gaps. I tested both directions (VPS to my server, my server to VPS) because some providers shape outbound differently than inbound.
Disk I/O tests used fio with libaio engine, 4k block size, 75/25 read/write mix, queue depth 32, direct I/O enabled to bypass OS cache. Each test wrote and read 8 GB total across four jobs. I let the system idle for ten minutes between runs.
All tests ran on freshly provisioned instances with only SSH, iperf3, and fio installed. No web servers, no databases, no background services that might skew results.
Cost wasn't part of the benchmark
Pricing changes too often to include in a performance comparison. The fastest provider in my tests isn't the cheapest, but it's not the most expensive either. Check current pricing directly since providers adjust rates based on demand and competition.
Some providers offer sustained-use discounts or reserved instance pricing that can cut costs significantly if you commit to annual billing. Others charge extra for premium bandwidth or backups. Factor total cost of ownership, not just the hourly rate.
So what should you test before committing?
Spin up a trial instance and run your own workload for 48 hours. Synthetic benchmarks show potential, but your actual application stack reveals how the VPS performs under your specific usage pattern.
Deploy your production stack—web server, database, cache layer, whatever you actually run—and monitor resource usage. Check CPU steal time with top to see if the hypervisor is overcommitted. Run iostat -x 5 during peak load to watch disk latency. Use mtr to trace network paths to your users.
# Check for CPU steal (hypervisor overcommit)
top -bn1 | grep "Cpu(s)"
# Watch disk performance under load
iostat -x 5
# Trace network path to key locations
mtr -rwc 100 your-users-location.example.com
CPU steal above 5% means you're competing with other tenants for physical cores. Disk await times over 10ms indicate storage contention. Packet loss or high jitter in mtr output points to network problems.
The workload-specific recommendations
For WordPress hosting with 10k+ daily visitors, disk IOPS and single-thread CPU performance matter most. The boot-time winner from my tests also delivers the best WordPress performance in my experience because those fast IOPS keep MySQL queries from piling up.
API servers and microservices care more about network latency and consistent throughput than raw disk speed. Pick a provider with excellent peering to your users' regions and test latency, not just bandwidth.
Batch processing, video encoding, or CI/CD runners benefit from sustained CPU performance and high disk throughput for large sequential writes. Look for providers that don't throttle CPU after burst credits run out.
What changed since 2025
Two providers in this test upgraded their network infrastructure in late 2025, which significantly improved their cross-region performance. Another switched from SATA to NVMe across their VPS fleet, jumping from 22k to 65k IOPS on the same pricing tier.
One provider that performed well in older comparisons has clearly oversold their nodes. Boot times that used to be 35 seconds now exceed two minutes, and disk I/O dropped 40% compared to tests I ran a year ago.
The market's getting more competitive. Several providers now offer AMD EPYC Milan or Genoa processors even on entry-level VPS plans, which wasn't common 18 months ago.
FAQ
How often should I re-benchmark my VPS provider?
Once a quarter if performance is acceptable, immediately if you notice slowdowns. Providers change hardware, adjust oversubscription ratios, and upgrade network gear regularly.
Can I trust provider-published benchmarks?
No. Run your own tests on production-like workloads. Marketing benchmarks use ideal conditions that don't reflect real usage.
Does the time of day affect VPS performance?
Yes, especially network and disk I/O. Test during your own peak traffic hours, not at 3 AM when the host node is idle.
What's the minimum acceptable IOPS for WordPress?
Around 30k random read IOPS for a busy site with a decent object cache. Below 20k and you'll see MySQL slowdowns under load.
Should I pick the fastest provider even if it costs more?
Depends on your margins. If slow page loads cost you conversions, the faster VPS pays for itself. For staging environments, save the money.
What to benchmark yourself
Don't trust anyone's numbers completely, including mine. Providers change hardware, network routes shift, and oversubscription ratios fluctuate based on customer load.
Spin up trial instances, run fio and iperf3, and measure what matters for your actual workload. A provider that's fast for my test pattern might be slow for yours, especially if you have unusual I/O patterns or serve users in regions I didn't test.
The best VPS is the one that performs well for your specific application under your real traffic patterns. Benchmarks are a starting point, not a final answer.