On VPS purchase pages, many vendors advertise "high-speed bandwidth," "low latency," and "enterprise-grade SSDs," but after purchasing, the VPS often feels sluggish, with connections always feeling delayed. Is this a marketing gimmick or a problem with your network? You want to confront the vendor, but you lack evidence.

Every time I get a new VPS, I don't rush to deploy my services; I spend half an hour testing it thoroughly. The data I get is much more reliable than what the vendors claim. Today, I'll share these tips with you.

Let's start with the most basic—latency and packet loss. This is what users notice most clearly. You can get a rough idea by typing a command:

ping -c 100 your_server_IP

Look at the final average latency and packet loss rate. An average latency under 50ms is excellent; 50-150ms is normal; over 200ms should raise concerns. A packet loss rate exceeding 1% indicates an unstable connection, which may cause lag during peak hours.

However, ping only tests the ICMP protocol; actual business operations use TCP. Therefore, a more reliable approach is to use tcping or mtr. mtr can tell you the latency and packet loss of each hop, helping you pinpoint the problem:

mtr --report your server IP

If you find a sudden spike in latency or abnormal packet loss rate on a particular hop, then that segment of the line has a problem. This is particularly useful; using this result to contact the provider is much more effective than simply saying "I feel it's slow."

After testing latency, it's time to test bandwidth. Many providers advertise shared bandwidth, which may not be fully utilized during peak hours. iperf3 can measure the actual bandwidth, but it requires iperf3 on both ends. If you only have the server, you can use wget to pull a test file:

wget -O /dev/null http://your server IP/100mb.test

Check the download speed and calculate the approximate Mbps. If it's advertised as 10M bandwidth but only 2M in reality, there's a problem. However, note that this speed is affected by your local network; it's best to test on several machines in different locations, or have a friend test it and take an average.

Next, let's look at disk performance. This is easily overlooked, but it has a significant impact. Databases, caching, and log read/write all rely on the disk. Use the `dd` command to get a rough estimate:

dd if=/dev/zero of=./test bs=1G count=1 oflag=direct

A typical SSD should achieve speeds above 300MB/s, with better ones reaching 500MB/s or even higher. If it's only a few tens of megabytes, you've hit a problem. Next, use `fio` to test random read/write. If 4K random read IOPS is below 10,000, running a database will be difficult.

fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --size=1G --numjobs=1 --runtime=60 --group_reporting

After testing these basic metrics, there are two more important things to test—outbound and inbound routing. Many vendors only tell you that their outbound routes are good, but the inbound routes are detours. You might not notice this, but the user experience is poor. You can use BestTrace to view the routing path:

wget https://cdn.ipip.net/17mon/besttrace_linux.zip

unzip besttrace_linux.zip

chmod +x besttrace

./besttrace -q 1 your_server_IP

For return route testing, you need to log in to the server and run the same command from the server to your local machine. If you find that the return route is not the same, or that it takes a long detour, there may be problems during peak hours.

Finally, a reminder: the timing of the speed test is very important. Don't just test in the early morning, when the network is most congested and the results look better. Test again during the evening peak (8 PM to 11 PM) to see if the bandwidth is fully utilized and if the packet loss rate spikes. Some providers offer ample bandwidth during normal times but secretly throttle speeds during peak hours; only testing during these times will reveal this.

If you have completed all the above tests and the data is satisfactory, then this VPS is basically reliable and you can use it with confidence. If you encounter problems during the speed test, don't rush to argue with the vendor. First, organize your speed test data screenshots, MTR results, and iperf3 output, and send them to customer service. Let the data speak for itself; it will give them a better basis for handling the issue.

Frankly, speed testing is about giving yourself a clear understanding. Knowing your machine's true capabilities gives you peace of mind and helps you troubleshoot problems later. After all, when it comes to servers, peace of mind is paramount.