Every VPS provider claims the fastest network and blazing SSD. Most support tickets I handle trace back to slow disk writes or congested uplinks, not application bugs. Numbers matter when you're paying monthly for compute you can't see or touch.
I spun up identical instances across nine providers—same OS image, same region group where possible, same tier of plan—and ran a battery of tests: cold boot to SSH, sequential and random disk I/O, ping round-trip from three continents, and a simple Apache Bench run against NGINX serving a static file. No affiliate spin. Just the data.
Testing methodology
Each provider got a 2 vCPU, 4 GB RAM instance running Ubuntu 22.04 LTS. I picked the nearest US East or EU West datacenter depending on the provider's footprint. Every test ran three times over forty-eight hours to smooth out transient network blips. I recorded the median.
Boot time started from the "power on" API call until SSH accepted my key. Disk I/O used fio with a 4k random write pattern and a 1M sequential write, both direct I/O to bypass cache. Network latency came from mtr reports to a London endpoint, a Singapore endpoint, and a New York endpoint, each for one hundred packets. The NGINX test fired ten thousand requests with ten concurrent workers using ab.
No tuning. Stock kernel, default scheduler, out-of-the-box partition layout. Your mileage will vary with custom kernels or RAID configs, but this reflects what you get on day one.
Boot time results
Cold boot speed tells you how fast you can scale horizontally or recover from a hypervisor migration. Most providers clocked between eighteen and thirty-two seconds from API call to SSH ready.
The fastest three were all KVM-based with virtio drivers and local NVMe backing. The slowest was a provider still using network-attached block storage for root volumes; it took almost ninety seconds because the initramfs had to negotiate iSCSI before mounting. If you auto-scale on traffic spikes, that lag adds up.
One provider—mid-tier pricing—booted in fourteen seconds. That same provider showed the highest disk write latency later, so they might be skimping on fsck or boot-time checks. Worth watching.
Disk I/O breakdown
Random 4k writes separate the real NVMe hosts from the ones selling you SSD labels on spinning rust or overprovisioned RAID arrays. I used this fio command:
fio --name=randwrite --ioengine=libaio --iodepth=16 --rw=randwrite \
--bs=4k --direct=1 --size=2G --numjobs=1 --runtime=60 --time_based \
--group_reporting
Top performer hit 45,000 IOPS. The median sat around 22,000. Two providers barely cracked 8,000 IOPS, and one of those advertised "enterprise NVMe" on the sales page. Check the fine print; shared NVMe still shares the controller queue.
Sequential writes matter for log-heavy apps or database dumps. The same top performer sustained 1.8 GB/s. Everyone else ranged from 600 MB/s to 1.1 GB/s. The slowest maxed out at 340 MB/s, which suggests thick-provisioned virtual disks over a SAN with congestion.
If you run PostgreSQL or MySQL with heavy insert traffic, random write IOPS is your bottleneck. For video transcoding or backup scripts, sequential throughput wins.
Network latency and routing
I fired mtr from each VPS to three targets: a Hetzner box in London, a Vultr instance in Singapore, and a Linode server in Newark. Latency depends on peering agreements and backbone hops, not raw bandwidth.
From US East VPS instances to Newark, most providers showed 1-3 ms round-trip. One outlier hit 18 ms because the traffic routed through Chicago first—suboptimal BGP or a cheaper transit provider.
To London, the spread was wider: 74 ms to 110 ms. The fastest had a direct peering arrangement with Level3. The slowest went through Cogent, added two extra hops, and showed 8% packet loss during peak EU hours.
Singapore was the real test. Latency ranged from 190 ms to 280 ms. Two providers with Asian POPs but US-based VPS still routed trans-Pacific traffic through their US backbone instead of handing off locally. If you serve global traffic, check the looking glass or run your own MTR before signing up.
HTTP throughput test
I installed NGINX with a default config and a 1 MB static HTML file, then hammered it with Apache Bench:
ab -n 10000 -c 10 https://vps-ip/testfile.html
This test is more about the network card and hypervisor overhead than the VPS itself. Most providers maxed out around 900-950 Mbps on a 1 Gbps port. One hit 1.7 Gbps because the plan included a 10 Gbps uplink.
Two providers throttled after the first few thousand requests. Throughput dropped from 920 Mbps to 480 Mbps mid-test. I confirmed with iftop that the bandwidth graph flattened. That's either a fair-use policy kicking in or noisy neighbors on the same hypervisor hogging the NIC queue. Neither mentioned burst limits in their terms.
If you expect steady traffic—streaming, large file downloads, API endpoints—pick a provider that guarantees the advertised rate or clearly documents burst vs. sustained.
What about CPU performance?
I didn't benchmark CPU because it's harder to compare apples-to-apples. Two vCPU can mean two threads on a single Xeon core or two full cores on an EPYC chip. Providers rarely disclose the exact model or the overcommit ratio.
For CPU-bound workloads like video encoding or cryptographic operations, request a trial and run your own sysbench or openssl speed test. The same provider might use different hardware in different regions.
Price-to-performance snapshot
The fastest provider on boot and disk I/O charged $24/month for the 2 vCPU plan. The median performer cost $12/month. The slowest billed $18/month but threw in weekly backups and a managed firewall.
Pure speed isn't the only variable. Uptime SLA, support response time, API quality, and snapshot costs all matter. I've seen clients move to a slightly slower host because the support team answered tickets in under an hour instead of two days.
That said, if your app is latency-sensitive—real-time APIs, game servers, high-frequency trading bots—the extra $12/month buys you measurable user experience.
How to test your own VPS
You can replicate these benchmarks in under an hour. SSH into your instance and install fio, mtr, and apache2-utils:
sudo apt update && sudo apt install -y fio mtr apache2-utils
Run the random write test I showed earlier. Compare your IOPS to the provider's marketing claims. If you're getting half the advertised number, open a ticket. Sometimes they'll migrate you to a less-crowded hypervisor.
For network tests, pick geographically diverse targets. Use public looking glasses or spin up a $5 droplet on another provider as a reference point. Run mtr for at least one hundred packets to catch intermittent routing issues.
Document your results before signing a long-term contract. Monthly plans let you bail if performance tanks after the first week.
Red flags I noticed
One provider auto-installed a monitoring agent that phoned home every sixty seconds. It added 4% CPU overhead on idle. I killed the process and performance jumped.
Another used a custom kernel with an out-of-tree I/O scheduler that broke fio Direct I/O mode. The vendor claimed it "optimized for cloud workloads," but standard benchmarks failed. If you can't run vanilla tooling, debugging production issues gets harder.
Two providers blocked outbound SMTP on port 25 without warning. That's common for anti-spam, but it should be in the firewall docs. One required a support ticket to whitelist your IP; the other sold a $3/month add-on for email relay.
Which provider should you pick?
It depends on your workload. Disk-heavy apps like Elasticsearch or time-series databases need high random IOPS. Media servers or backup solutions want sequential throughput. Game servers and API gateways care about latency and jitter.
The provider that won on boot time and disk I/O had the worst support reputation in the hosting forums. The one with 24/7 chat support and a generous SLA came in fourth on raw speed but had zero downtime over the forty-eight-hour test window.
I'd rather have a VPS that boots in thirty seconds and responds to tickets than one that boots in fourteen and leaves you hanging when something breaks at 2 AM.
Run the tests above during your trial period. Combine the numbers with support quality and pricing. If you're migrating from shared hosting, even a median VPS will feel fast. If you're moving from a dedicated server, watch the IOPS closely.
What to prioritize after speed
Speed matters, but it's not the whole story. Check the provider's uptime history on status pages or third-party monitors. Read support tickets in forums to see how they handle outages. Confirm the backup and snapshot policy—some charge per GB, others bundle it.
If your app can tolerate an extra 50 ms of latency, a provider with solid support and transparent pricing might serve you better than the absolute fastest instance with 72-hour ticket queues. Run the tests, then weigh the full picture.