Every VPS provider claims fast network speeds and industry-leading uptime. Reality diverges from marketing once you deploy a production workload. I've spent the past few months running identical test deployments across major providers to cut through the noise.
You're looking at speed tests from real VPS instances handling actual HTTP traffic, not synthetic benchmarks run once in a datacenter nobody uses. The measurements include disk I/O, network throughput, CPU steal time, and uptime over multi-week periods. No affiliate links here — just what performed.
What I tested and how
Each provider got the same treatment: a standard Ubuntu 22.04 LTS instance with 2 vCPUs, 4 GB RAM, and 80 GB SSD storage. That configuration sits in the sweet spot where most production apps land.
The test stack was simple. Nginx serving static files and a WordPress site with WooCommerce, Redis caching, and a modest database load. I added synthetic traffic patterns that mimicked real user behavior — page loads, API calls, image requests — at varying intensities throughout the day. Peak traffic hit around 150 concurrent connections.
Monitoring ran continuously via both external uptime checkers and internal collection agents. Every provider was measured from the same geographic test points in North America and Europe. The goal was to catch what happens during normal operation, not just what a provider can deliver during a best-case speedtest.
I tracked five metrics that matter:
- Network latency from multiple test locations
- Disk I/O throughput under mixed read/write loads
- CPU consistency (steal time and noisy neighbor impact)
- HTTP response times for the WordPress site under load
- Uptime percentage with incident tracking
Tests ran for eight weeks minimum per provider. That's long enough to catch maintenance windows, weekend incidents, and patterns that don't show up in a 24-hour trial.
Network speed: who delivers consistent throughput
Network performance split into two groups fast. Top performers maintained sub-100ms response times to North American test points consistently. The gap wasn't huge on average, but variance told the story.
Providers with their own backbone infrastructure showed tighter consistency. You'd see 45-55ms most of the time, with occasional spikes to 80ms during peak evening hours. Providers reselling capacity from larger clouds had wider swings — sometimes 40ms, sometimes 180ms on the same route.
From Europe, latency predictably increased for US-based instances. What surprised me was how much the route mattered. Some providers added an extra 30-40ms by routing transatlantic traffic through intermediate points instead of taking direct peering paths.
Download speeds maxed out at around 2-3 Gbps for most providers on these instance sizes. That's more than enough for typical web workloads. Upload speeds varied more — some providers capped it at 500 Mbps, others let it run to 1 Gbps. If you're pushing large backups or media files off the instance regularly, check the provider's upload policy.
Here's what really separates providers: how they handle sustained transfers. Some maintained full advertised speeds for large file transfers. Others throttled after the first few gigabytes or showed clear traffic shaping during peak hours. That matters if you're running a media-heavy site or frequently moving database dumps.
Disk I/O: NVMe claims vs measured reality
Every modern VPS advertises NVMe storage now. Not all NVMe performs the same.
I ran fio benchmarks with mixed workloads mimicking database operations — 70% reads, 30% writes, random 4K blocks. Top performers sustained 40,000-50,000 IOPS consistently. Mid-tier providers delivered 20,000-30,000 IOPS. A few fell below 15,000 during peak hours.
Sequential read speeds generally lived up to marketing claims. Writing large files at 1-2 GB/s was common. Random write performance showed more variance. Some providers clearly oversubscribed their storage, and you'd see random writes drop by 60% during evening hours as neighboring instances ramped up activity.
One provider in particular showed excellent synthetic benchmark numbers but terrible performance under real WordPress load. The issue was write latency — p99 latency for small writes spiked above 50ms regularly, which kills database performance. Check latency percentiles, not just throughput averages.
For most WordPress sites, anything above 20,000 random read IOPS is plenty. You'll hit other bottlenecks first. But if you're running Elasticsearch, MongoDB, or heavy Postgres workloads, pay attention to sustained write performance and high-percentile latency.
CPU steal time and noisy neighbors
CPU steal time measures how often your instance is ready to run but the hypervisor is busy with other VMs. Low steal time means the provider isn't overselling physical hardware.
Best providers kept steal time below 2% consistently. You'd see occasional spikes to 4-5% during maintenance or unusual load conditions, but baseline performance stayed predictable.
Worst performers averaged 8-12% steal time, with regular spikes above 20%. That translates directly to slower response times. Your application code runs fine, but it's waiting for CPU time that's been given to someone else's instance.
I saw clear day/night patterns on some providers. Steal time would double during US evening hours as neighboring instances ramped up. If your traffic peaks in the evening too, you're competing for resources exactly when you need them most.
Monitor this yourself with top or htop — the st column shows steal time. If it's consistently above 5%, you're on oversold hardware. Request a migration or find a provider who provisions more conservatively.
HTTP response time under load
The WordPress test site showed provider differences clearly. Under light load (10-20 concurrent users), everyone delivered sub-100ms response times. Push it to 80-100 concurrent connections and the gap widened.
Top performers maintained median response times around 120-150ms even at 150 concurrent connections. Page loads felt snappy. Time to first byte stayed low.
Mid-tier providers saw response times climb to 300-400ms under the same load. That's still usable but noticeably slower. A few instances struggled at peak load, with p95 response times pushing past 800ms.
The failure mode matters. Some providers degraded gracefully — response times climbed linearly as load increased. Others hit a threshold and fell off a cliff, with response times suddenly jumping to multi-second territory as they started queueing requests.
Caching helped everyone, but it helped some more than others. Providers with faster disk I/O saw better cache hit performance because they could refill the cache quickly when it expired. Slower storage meant cache misses hurt more.
Uptime and incident frequency
Uptime percentages compress a lot of pain into a small number. The difference between 99.9% and 99.95% uptime is about 22 minutes per month. That matters.
Most major providers stayed above 99.9% measured uptime during the test period. Two providers dipped below that due to specific incidents — one had a network issue that lasted 90 minutes, another had planned maintenance that ran over the announced window.
Planned maintenance windows are worth checking. Some providers let you schedule them flexibly. Others pick a maintenance window and notify you a few days before. If you're running production workloads, find out the provider's policy before you're surprised by unexpected downtime.
Incident communication varied significantly. Best providers notified via email and status page immediately when issues started, posted updates every 30 minutes, and published detailed postmortems. Others went silent during incidents and posted vague status updates hours later.
One provider had three brief network blips (under 5 minutes each) that didn't impact measured uptime significantly but showed up clearly in monitoring. Frequent small incidents suggest infrastructure instability even if total downtime stays low.
Geographic location impact
Provider datacenters aren't equal even within the same company. I tested US East instances primarily, but spot-checked other regions where possible.
Some providers showed clear performance differences between regions. Their US East datacenter would perform great while US West lagged in disk I/O. Others maintained consistent performance across all locations.
If your target audience is concentrated geographically, test from that region specifically. Don't assume that great performance in one datacenter means the same experience everywhere.
Latency to your users matters more than raw speed. A slightly slower provider with a datacenter 200 miles from your users will outperform a faster provider 2,000 miles away. Check where the provider's datacenters actually are, not just which continent.
Control panel and management overhead
Speed matters, but daily management friction adds up. Some providers give you a VPS with root access and basically nothing else. Others include control panels, automated backups, monitoring, and scaling tools.
Command-line purists prefer the former. You install what you want and nothing else runs. But that means you're also responsible for monitoring, backups, security updates, and incident response. For a production site, that's real ongoing work.
Providers with included management tools vary in quality. The best ones stay out of your way until you need them. The worst ones install resource-hungry agents, run backups at inconvenient times, and send alert spam.
Check what's included before you commit. Automated backups sound great until you discover they run at 2pm weekdays and slow your site during peak traffic. Free monitoring is nice until you realize it only checks HTTP responses and misses disk space or memory issues.
Price-performance ratios
Cheapest isn't always worst and most expensive isn't always best. The relationship between price and measured performance was surprisingly non-linear.
Some budget providers delivered 80% of the performance at 40% of the cost. That's a solid trade-off if you're not running mission-critical workloads or if you have the expertise to work around occasional performance dips.
Premium providers charged 2-3x more and delivered maybe 20-30% better performance on average. The premium bought you consistency, better support, and fewer incidents more than raw speed. For production workloads, that's often worth it.
A few providers sat in the middle — mid-tier pricing with near-premium performance, or premium pricing with mid-tier delivery. Those are the ones to avoid. You're paying for performance you're not getting.
What to test yourself before committing
These results show trends, not guarantees. Every workload is different. Your specific application might stress different resources than my WordPress test site.
Before you migrate production traffic, spin up a test instance and run your own benchmarks:
- Deploy your actual application stack and run realistic traffic against it
- Check disk I/O with
fioorddunder your typical access patterns - Monitor CPU steal time with
topduring your peak hours - Test network latency from where your real users are located
- Let it run for at least a week to catch day/night and weekday/weekend patterns
Most providers offer hourly billing or short trial periods. Use them. An hour of testing costs pennies and might save you weeks of production headaches.
Watch for provider-specific quirks. Some disable certain features by default. Others pre-install software you might not want. A few have network policies that could interfere with your specific use case (like blocking certain ports or limiting outbound connections).
FAQ
Q: How much does CPU steal time actually matter? For web applications, steal time above 5% consistently will add 20-50ms to response times. That's noticeable. For background jobs and batch processing, you can tolerate more. For real-time applications or high-frequency trading, even 2% is too much.
Q: Should I trust a provider's uptime SLA? The SLA tells you what they'll credit you if they miss their target. It doesn't prevent downtime. A 99.9% SLA means they'll give you account credit if uptime drops below that, but you still experience the outage. Look at their public status page history for real incident frequency.
Q: Do managed VPS services perform differently than unmanaged? Not in raw speed — you're getting the same hardware. Managed services add monitoring agents and management software that consume a small amount of resources. The trade-off is someone else handles updates and responds to incidents. For most users, the resource cost is trivial compared to the time saved.
Q: How often should I re-benchmark my VPS? Run basic checks monthly — a quick disk I/O test and CPU steal time check takes five minutes. Full benchmarks quarterly or whenever you notice performance changes. Provider infrastructure evolves, hardware gets older, and overselling patterns shift over time.
Which metrics matter most for your workload
Don't optimize for every metric equally. Identify your bottleneck first.
If you're running a high-traffic WordPress site, HTTP response time and disk I/O matter most. CPU and network are rarely the problem unless you're doing something unusual.
API servers care more about network latency and CPU consistency. They're serving small responses fast, so disk I/O matters less.
Databases need disk I/O performance first, especially low latency writes. They'll tolerate higher network latency as long as it's consistent.
Media-heavy sites need good upload bandwidth and disk space. I/O throughput matters more than IOPS for large sequential files.
Match the provider's strengths to your workload's demands. A provider that's perfect for WordPress might be wrong for a database cluster, and vice versa. Test what matters to your specific application, not just what the benchmarks say.