You’ve just purchased a new VPS advertised as having "premium CN2 GIA routing" with "low latency and high bandwidth"—but how does it actually perform? Does the speed drop during evening peak hours? Is the CPU oversold? Do disk read/write speeds meet specifications? You can't answer these questions without running a few tests.

This article guides you step-by-step through a comprehensive performance evaluation using mainstream tools, covering the sequence of "network latency → bandwidth throughput → hardware benchmarking." Whether you are a novice or an expert, following these steps will yield a reliable performance report.

Pre-test Preparation

Many testing tools require two machines working in tandem. It is recommended to use your VPS as the server and another machine under your control (such as a home computer, a company test machine, or another cloud server) as the client. This setup measures the raw throughput of the connection between the two points, eliminating interference from third-party node speed limits.

The preparation checklist is simple: the server to be tested (Linux system required, with root or sudo privileges), a peer machine (another Linux server or a standard Windows/macOS machine), and firewall port configuration (iperf3 uses TCP and UDP port 5201 by default).

There is a rule of thumb when selecting the peer machine: its bandwidth capacity should not be lower than the rated bandwidth of the server being tested. If you use a home broadband connection with only 100 Mbps upload speed to test a 1 Gbps VPS, the result will inevitably cap out at around 94 Mbps; such data indicates a bottleneck at the peer machine rather than an issue with the server itself.

Network Latency Testing: Ping and MTR

Ping Test: Basic Connectivity Check

Ping is the most common method for testing latency; it assesses network response speed by sending ICMP packets and calculating the round-trip time. Run `ping -c 100 <target_IP>` in a Linux or macOS terminal, or `ping -n 100 <target_IP>` on Windows.

Focus on three key metrics: average latency, maximum latency, and packet loss rate. For CN2 GIA routes from mainland China to the US West Coast, a normal average latency falls between 130 ms and 180 ms; for CN2 GIA routes to Hong Kong, it is typically between 30 ms and 60 ms. If latency exceeds 300 ms or packet loss exceeds 5%, the user experience will be noticeably impacted. The limitation of Ping is that it only tells you whether the result is good or bad, not where the problem lies. Furthermore, Ping relies on the ICMP protocol; many network devices prioritize or simply drop ICMP packets, leading to discrepancies between Ping results and the actual experience of TCP-based services.

MTR Testing: Pinpointing the Problematic Hop

MTR (My Traceroute) combines the functions of Ping and traceroute, continuously displaying latency and packet loss rates for each routing hop; it is a core tool for troubleshooting network issues.

Installation and Execution:

Ubuntu/Debian

apt-get install mtr -y

CentOS/RHEL

yum install mtr -y

Report mode, sending 300 probe packets:

mtr -rwzc 300 [Target IP]

A common misconception when interpreting MTR results is assuming that 30% packet loss at an intermediate hop implies packet loss for actual services. If subsequent hops return to 0% packet loss, the router at that specific hop is likely just rate-limiting ICMP responses. A genuine link issue is more likely indicated if packet loss persists across all subsequent nodes starting from a specific hop.

A more reliable recording method involves running tests against the same target at 10:00, 15:00, 21:00, and 01:00, clearly marking the time in the filenames. If anomalies occur only during evening peak hours—specifically at cross-border egress points or on the return path—screenshots and text logs help service providers determine whether the issue stems from congestion, route flapping, or upstream policy adjustments.

Percentiles: Closer to the Real-World Experience Than Averages

Looking solely at average latency is insufficient. Consider a VPS connecting to a Shanghai test point: while the average latency is 160ms, the 95th percentile latency reaches 420ms, accompanied by 2%–5% packet loss between 20:00 and 23:30 nightly. This scenario impacts the SSH and backend management experience far more than a connection with a "smooth" profile averaging 180ms.

It is recommended to record at least four metrics: average latency, maximum latency, packet loss rate, and 95th or 99th percentile latency. While the average value answers "how slow is it usually?", percentile values ​​answer "how severe are the occasional spikes?" Bandwidth Throughput Testing: iperf3 vs. Speedtest CLI

iperf3: Precise Throughput Testing

iperf3 is the gold-standard tool for network performance testing. It simulates real-world data transmission using TCP/UDP protocols, allowing for accurate measurement of actual bandwidth between two points.

Server-side setup:

Installation

sudo apt install -y iperf3

Start the server

iperf3 -s

Client-side testing:

Test upload bandwidth (Client → Server)

iperf3 -c Server_IP -t 60

Test download bandwidth (Server → Client) using the -R flag

iperf3 -c Server_IP -R -t 60

Multi-threaded test (10 concurrent streams)

iperf3 -c Server_IP -P 10 -t 30

Focus on two key metrics: measured throughput and retransmission count. If the measured bandwidth is significantly lower than the advertised rate, the bandwidth may be overstated or subject to overselling (shared capacity). A high retransmission count indicates packet loss on the link.

Speedtest CLI: Quick Public Network Speed ​​Test

For a quick, general speed check, you can use the official Ookla Speedtest CLI.

Ubuntu/Debian

curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | sudo

sudo apt install speedtest -y

Run

speedtest

Speedtest automatically selects the nearest server and reports ping latency, download speed, and upload speed. Results may fluctuate due to server load or routing changes; it is recommended to run multiple tests at different times and calculate the average.

Hardware Benchmarking: YABS and bench.sh

bench.sh: Get the Lowdown on a New Machine in 5 Minutes

bench.sh is a classic "one-click" benchmarking script in the VPS community. A single command allows you to test system specifications, disk read/write speeds, and network speeds to global nodes. wget -qO- bench.sh |

or

curl -Lso- bench.sh |

bench.sh primarily outputs three categories of information: system details (CPU model/core count, RAM, Swap, OS version, TCP congestion control algorithm, virtualization type), disk I/O speed (calculated by averaging three sequential write operations using the `dd` command), and network speed tests (upload/download speeds and latency to various global nodes).

The limitation of bench.sh is that it does not perform CPU benchmark scoring. If you require more detailed CPU performance data, you should use YABS (described below).

YABS: An Industry-Standard Comprehensive Benchmark

YABS (Yet Another Bench Script) is currently the most reliable comprehensive benchmarking tool; maintained by developer masonr, it boasts high activity levels on GitHub. It automatically utilizes Geekbench 6 for CPU testing, fio for disk testing, and iperf3 for network testing, with a full run taking approximately 10–30 minutes.

curl -sL yabs.sh |

Interpreting CPU Benchmark Scores: Geekbench 6 is an authoritative, cross-platform benchmarking tool. A single-core score below 400 indicates weak CPU performance, potentially suggesting severe resource overselling; scores between 400 and 800 represent an average level; 800 to 1,200 is considered good; and scores exceeding 1,200 fall into the excellent category.

Interpreting Disk I/O Speeds: YABS tests read/write speeds across four block sizes—4K, 64K, 512K, and 1M—allowing you to identify the disk type. Speeds below 200 MB/s indicate an HDD (mechanical hard drive); 200–500 MB/s indicates a standard SATA SSD; 500–3,000 MB/s indicates an NVMe SSD; and speeds exceeding 3,000 MB/s indicate a high-end NVMe RAID array.

Specialized Disk Testing: fio

If you require a more in-depth analysis of disk performance, you can run fio independently for specialized testing. Use the following command to test 4K random read/write performance (simulating a database scenario):

Installation

apt install fio -y

4K Random Read/Write Test

fio --name=randrw --ioengine=libaio --rw=randrw --bs=4k \

--size=1G --numjobs=1 --runtime=60 --group_reporting

Focus on IOPS (Input/Output Operations Per Second) and latency. 4K random read/write IOPS below 20K indicate weak disk performance; NVMe SSDs typically achieve over 50K. Read/write latency under 5ms is excellent, while latency exceeding 10ms can impact database performance.

How to interpret the results?

After running the tests and obtaining the performance report, evaluate the results against these standards:

Network Quality Reference: For Hong Kong CN2 GIA connections, average latency of 30–60ms is excellent, 60–100ms is good, and anything over 150ms warrants concern. For US West Coast CN2 GIA connections, 130–180ms is considered normal. Ideally, packet loss should be close to 0%; a rate exceeding 5% during peak hours indicates substandard connection quality.

Hardware Performance Reference: A Geekbench 6 single-core score above 800 is solid, while over 1,200 is excellent. Disk 4K random read/write IOPS above 20K is acceptable, and over 50K is excellent. A single-core CPU score below 400 suggests potential severe overselling.

Bandwidth Compliance: Actual throughput reaching over 90% of the advertised rate is excellent; 70%–90% is acceptable; anything below 50% indicates inflated specifications or excessive sharing/overselling.

Post-Testing: Jtti Ensures Underlying Performance

Once testing is complete, you can assess the true capabilities of a VPS. However, testing is merely a tool; the ultimate determinant of your service experience is the server's underlying hardware quality.

Jtti’s cloud server solutions provide the hardware foundation necessary for high performance. Enterprise-grade NVMe SSDs come standard across the entire lineup, delivering 4K random read/write IOPS in fio tests that far exceed those of standard SATA SSDs. Our Hong Kong and US nodes connect via premium CN2 GIA routes with optimized direct connectivity across all major carriers; MTR tests confirm that return traffic travels entirely through dedicated 59.43 nodes, maintaining a packet loss rate below 0.5% even during peak evening hours. All plans feature dedicated bandwidth; iperf3 test results closely match the advertised specifications, ensuring speed readings are not skewed by "noisy neighbors" competing for resources.

Our lifetime recurring discount policy guarantees that the renewal price remains the same as the initial purchase price, ensuring predictable long-term operating costs amidst the anticipated 2026 price adjustments.

A VPS's true performance isn't defined by vendor claims, but by your own testing. Visit the Jtti official website to view full specifications and current promotions for our Hong Kong and US CN2 cloud servers, and select a server that stands up to rigorous performance benchmarking.