How to Benchmark a VPS Line Before You Buy

Every VPS provider's landing page promises the same thing: premium network, ultra-low latency, blazing fast. Then you deploy, your team in another country tries to use the thing at 9pm, and SSH feels like it's routed through the moon. The specs on the sales page — CPU, RAM, disk — are the easy part. What actually determines whether a VPS feels fast is the line: the network path between the server and the people using it. And unlike CPU benchmarks, line quality is almost never in the marketing copy, because for cheap providers it's embarrassingly bad. Here's how to test a line properly, before your money and your workloads are committed. Most providers offer hourly billing, a trial, or a money-back window — one small test instance for a day is all you need. Before you spend anything: test IPs and looking glasses You can often benchmark a provider's line without buying at all. Serious providers publish: Test IPs — one address per datacenter location, published precisely so you can ping and route-test them. Looking glass pages — a web tool that runs ping/mtr from the provider's network toward an address you specify. This gives you the server-to-you direction, which you cannot measure any other way before purchase. Test files — 100MB/1GB downloads hosted in each location, for a crude but honest throughput check from your desk. Run the ping and MTR tests below against the test IP for the exact location you'd buy. If a provider offers no test IP, no looking glass, and no test file, ask support for one. If they refuse, that tells you how the benchmark would have gone. Know your latency floor before you start Latency has a hard physical limit: light in fiber. Knowing the floor for your route stops you from chasing impossible numbers — and exposes providers whose "optimized" line is somehow slower than physics plus a reasonable margin: Route Realistic good latency Same metro 1–10 ms US West ↔ US East 60–80 ms Asia (Tokyo) ↔ US West (Los Angeles) 100–130 ms China ↔ US West (Los Angeles) 130–180 ms China ↔ US East 190–240 ms Europe ↔ US East 70–100 ms If a provider's Los Angeles box pings at 260ms from Shanghai while a competitor's sits at 150ms, the difference is routing quality, not distance — and it's exactly the difference premium transit is supposed to buy you. Test 1: Ping — necessary, wildly insufficient From your actual location (not a random test node), run: ping -c 20 Read three numbers: Average latency. Rough physics: within a continent, expect 5–50ms. Cross-Pacific (Asia ↔ US West Coast), a good line lands around 130–180ms. Asia ↔ US East Coast, 200ms+. If you're seeing numbers far above the geographic floor, the route is taking a scenic detour. Packet loss. This is the number that actually ruins your day. 0% is normal. Even 1–2% loss makes SSH stutter, RDP unusable, and video calls fall apart. Sustained loss above 3% means walk away. Jitter (min–max spread). 138ms average with a range of 135–141ms is a healthy line. The same average with spikes to 400ms means congestion — and it will always be worst exactly when you need it most. Critical: run this test at peak hours (roughly 8–11pm in the timezone of whoever will use the server). Almost every line looks fine at 4am. Congested bargain routes fall apart in the evening, and that's the only version of the line your users will ever meet. Test 2: MTR — find out where it breaks Ping tells you something is wrong. MTR tells you where: mtr --report-wide # or, from Windows: WinMTR / tracert won't show loss per hop — prefer mtr How to read it: Loss at the final hop is the only loss that fully counts. Intermediate hops often deprioritize ICMP and show fake loss; if the last hop is clean, the line is clean. Watch where latency jumps. A single big jump at an ocean crossing is normal physics. A big jump within the same city means you're being handed off to cheap congested transit. Note the carriers in the path. For China-facing traffic, seeing the path stay on premium transit (e.g., China Telecom's CN2, AS4809) all the way is exactly what you paid for. If the route dumps onto congested commodity transit for the last stretch, that's the classic "premium on the invoice, bargain in reality" pattern — and it explains every evening slowdown. Also test the return path: run mtr from the server back to your IP. Routes are asymmetric; a great outbound path with a garbage return path performs exactly like a garbage line. Test 3: Throughput — use a real speed test script Latency is half the story. For bandwidth, run a multi-node speed test from the server itself. The community-standard one-liners (NodeBench-type scripts, or the classic bench.sh style suites) will test against several endpoints and also report disk and CPU, which is handy for catching oversold hosts. Or use iperf3 against a known endpoint for a cleaner measurement: iperf3 -c -P 4 -R What to compare: Single-thread vs. multi-thread speed. A line that hits full speed only with 8 parallel streams but crawls on a single connection has a throughput-per-flow problem — and most real applications (SSH, single file transfers, streaming) are single-flow. Speed to your region, not to the provider's favorite test node in the same datacenter. A result of "9 Gbps to a server 2km away" tells you nothing about the 40 Mbps your team will actually get across an ocean. Test 4: The boring tests that catch liars Disk: fio or even the script results above. If a "datacenter SSD" benchmarks like a spinning disk, the host is oversold and everything else will degrade too. CPU steal: in top, watch %st. Sustained steal above a few percent means the host is oversubscribed — your neighbors are eating your CPU. Consistency: run the same tests morning and evening. A quality provider's numbers barely move. A bargain bin host can swing 5–10x between off-peak and peak. A quick interpretation table Symptom Likely cause Great at 10am, terrible at 9pm Congested cheap transit, oversold peak capacity Low ping, but everything feels slow Single-flow throughput cap or loss on return path High jitter, occasional freezes Packet loss at a handoff hop — check MTR Fast to nearby nodes, slow to you Route optimized for looks, not for your geography Numbers swing wildly day to day Oversold host or unstable routing The buying rule this produces Never buy a year of VPS on an untested line because the annual plan is 40% off. Buy a month (or a day), benchmark at peak hours from the places that will actually use it, and only then commit. The providers worth keeping publish test IPs or looking-glass pages precisely so you can do this — treat the absence of any way to test as data in itself. For context, when I benchmarked lines for US/Japan/Hong Kong deployments, the boxes at 8e.net held up well in exactly these peak-hour tests (and code LH1111 gets 20% off if you end up there) — but run your own numbers from your own desk. A line is only good if it's good to you, and now you know how to prove it before you pay for it.