How to test VPS ping and speed before you pay

Two hosts with identical plans in the same city can give different ping to your users, different download speed and disks that differ several times in performance. The plan card will not tell you that, but you can check it. The network can almost always be measured before you pay: many hosts publish test addresses and looking glass pages. CPU and disk are checked in the first minutes after launch, and if the result is poor, the server can be returned within a trial period or deleted under hourly billing. Below is the order of checks and reference values for reading the results.

What you can check before paying

Hosts that are confident in their network publish tools to test it. Look in the site footer, in the "Data centers" or "Network" section, or in the knowledge base.

• A test IP address for each location. You can ping it and run a trace from your own computer to see the real latency and route from your network.
• Test files of 100 MB, 1 GB or more. Downloading one shows how fast a server in that location delivers data to your provider.
• Looking glass: a web page where you can run ping or traceroute, or look up the BGP route from the host's router to any address. It is the view from the other side: how the host's network sees your office or your users.

The Accsly catalog collects hosts' test addresses and looking glass links and shows them where they are known. If a host has no such tools, ask support for a test IP; it usually takes a few minutes.

Ping, mtr and traceroute: measuring latency

Measure latency from where the server's users are: from the office, from home and, for a public service, from several cities. A ping from one place says nothing about another.

• ping -c 50 address shows average latency and jitter. Look at the maximum and packet loss, not just the average: a steady 40 ms is better than 25 ms with spikes to 200.
• mtr -rwc 100 address (WinMTR or pathping on Windows) shows latency and loss at every hop. It is the main tool when you need to find where exactly time is lost.
• traceroute or tracert shows the packet path. Hop names reveal which networks and countries the traffic crosses: sometimes a server in a neighbouring country is reached through a route on the other side of the continent.

How to read mtr: loss at an intermediate hop with zero loss at the destination is usually not a problem, since many routers simply do not answer diagnostic requests. The warning sign is loss that starts at one hop and continues to the end of the route, or a sharp latency jump on a specific segment.

Reference values: within one city 1–5 ms, within a mid-sized European country 5–20 ms, Frankfurt to Amsterdam under 10 ms, Western Europe to the US East Coast 80–100 ms, US East to West Coast 60–80 ms, Europe to Asia 150 ms or more. For a website a difference of 30–40 ms is barely noticeable; for a game server, VoIP or remote desktop it is.

Testing from several cities

If the server's audience is spread across a country or several countries, one measurement from the office is not enough. Free distributed testing services such as Globalping and RIPE Atlas run ping, traceroute and HTTP requests from hundreds of probes on different providers. They show which users have a long route to the data centre and where packets are lost. This is especially useful when choosing between two locations: a server that is 5 ms faster from London may be noticeably slower for users in Southern Europe or Scandinavia. For a service with users in several regions, a location with even latency for everyone is better than the fastest one for a single city.

Download speed and test files

Download a 100 MB test file from each location you are considering: curl -o /dev/null https://…/100mb.test shows the average speed. Keep in mind that the result is limited by the slowest link: your home connection, Wi-Fi and your provider's evening congestion. So compare hosts with each other from the same computer at the same time, not with the figures in the plan.

Popular speed test sites measure the link to the server nearest to you, not to the host, so they are of little use for choosing a VPS. If a host has no test file, this check waits until the server is running.

Trial periods, refunds and hourly billing

CPU and disk cannot be measured before launch, so it matters how cheaply you can try a server.

• A free trial of a day to a week on the plan or a reduced version of it. Some hosts require phone or ID verification. See VPS with a free trial.
• A money-back period in the first days. Read the terms: refunds often cover only the first order, exclude licences and extra IPs, and go back only to the original payment method.
• Hourly billing. The easiest way to compare several hosts: start a server, run the tests within an hour and delete it, paying only for the time used. See VPS with hourly billing.

With monthly billing and no trial or refund, start with the shortest term even if annual payment is cheaper: a yearly discount will not make up for a server that does not fit.

What to measure in the first hour after launch

First check that you got what was promised: lscpu shows the CPU model and core count, free -h the memory, lsblk and df -h the disk. Then run three tests.

Disk: fio. For databases and websites, random I/O matters, not sequential writes. A typical test: fio --name=rand --rw=randrw --bs=4k --size=1G --iodepth=32 --direct=1 --runtime=60 --time_based. Reference values: a good NVMe drive gives tens of thousands of IOPS at 4 KB blocks, a SATA SSD from a few thousand to low tens of thousands, an HDD hundreds. If an "NVMe" plan delivers a couple of thousand IOPS, the disk is heavily throttled or overloaded by neighbours.

CPU: sysbench or Geekbench. sysbench cpu --threads=1 run and the same test on all cores show single-thread and whole-server performance. Geekbench is handy because the result can be compared with its public database. Run the test several times at different hours: if results jump around, the cores are shared and busy with neighbours.

Network: iperf3. A test between two of your servers or to a public iperf3 server shows the real port capacity: iperf3 -c address -P 4 -t 30, plus -R for the reverse direction. On a gigabit port expect 800–940 Mbps; if you get 100–200, the port is capped or shared.

If the server will send mail, also check that the assigned IP address is not on spam blocklists, and that latency from the server to your users matches what you measured before paying.

Common testing mistakes

• Testing over Wi-Fi. A wireless network adds latency and loss that the host does not have. Use a cable for measurements.
• One measurement at noon. Networks and host neighbours behave differently in the morning and in the evening, so a single run can mislead you.
• Disk test with cache. Without --direct=1, fio measures memory rather than the disk, and the result is inflated several times.
• A test that is too short. Some plans are fast for the first minutes and then throttle the disk or CPU. Run tests for at least a minute.

How to compare results

• Compare hosts with the same set of tests, from the same points, at the same time of day.
• Repeat the measurements in the evening: overloaded hosts and links show up at peak hours.
• Look at consistency, not the best result: spread tells you more about overselling than the average.
• Write the results down in a table; a month later they help if the server starts to slow down.
• Judge by your task: for a website, disk and latency to the audience matter most; for code builds, the CPU; for file storage, the port.

Which plan parameters to check before testing is covered in how to choose a VPS. You can filter plans with a trial, hourly billing and the right location in the VPS search.