To determine the true performance of a VPS, don't just rely on the provider's claims—test it yourself.

A provider might advertise a new VPS as having "premium CN2 GIA routing," "low latency," and "high bandwidth," but how does it actually perform in practice? Does speed drop during peak evening 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 assessment using standard tools, covering the sequence of network latency → bandwidth throughput → hardware benchmarks. Whether you are a novice or an expert, following these steps will yield a reliable performance report.

Pre-test Preparation: A Peer Machine

Many testing tools utilize a client-server architecture requiring two machines. We recommend using your VPS as the server and another machine under your control (such as a home PC, a company test machine, or another cloud server) as the client. This setup measures the raw throughput between the two points, eliminating interference from third-party node speed limits.

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

A rule of thumb when selecting a 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 reflects a bottleneck at the peer machine rather than an issue with the server itself.

Latency Testing: Ping, MTR, and Percentiles

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 connections from mainland China to the US West Coast, the typical average latency ranges from 130ms to 180ms; for connections to Hong Kong via CN2 GIA, it is usually between 30ms and 60ms. If latency exceeds 300ms or packet loss exceeds 5%, the user experience will be noticeably affected.

The limitation of Ping is that it only indicates whether the result is good or bad, without revealing exactly 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 Test: 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 key 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 actual service packet loss. If subsequent hops return to 0% packet loss, the issue is usually just that specific router limiting ICMP responses. A genuine link problem is more likely indicated if packet loss persists across all nodes following 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 during evening peak hours occur only at the cross-border egress or return path, screenshots and text logs can help the service provider determine whether the issue stems from congestion, route flapping, or upstream policy adjustments.

Percentiles: Closer to the Real Experience than Averages

Looking solely at average latency is insufficient. Consider a VPS connecting to a Shanghai test point: while the average latency might be 160ms, the 95th percentile latency could reach 420ms, accompanied by 2%–5% packet loss every night between 20:00 and 23:30. This scenario has a greater negative impact on SSH sessions and backend management tasks than a connection with a steady 180ms average latency and a smooth performance curve. It is recommended to track 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 ​​reveal "how severe are occasional spikes?" For services like WordPress backends, APIs, or gaming servers, the latter often better reflects the actual user experience.

Reference criteria: Minor fluctuations (packet loss <0.3%, 95th percentile latency ≤1.8x average latency) usually warrant continued monitoring; noticeable jitter (packet loss 0.5%–2%, or 95th percentile latency >2.5x average latency) causes perceptible lag in backend operations; severe anomalies (packet loss >3% for over 10 consecutive minutes, or maximum latency repeatedly exceeding 1000ms) require documenting evidence and contacting the service provider.

Bandwidth throughput test: iperf3

While MTR visualizes the network path, it does not indicate whether the bandwidth is fully utilized. iperf3 is a tool specifically designed for throughput testing; it establishes a controlled data stream directly between two machines, allowing for separate tests of upload and download speeds, concurrent connections, and even UDP-based packet loss verification.

Server-side deployment:

Ubuntu/Debian

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

Interpreting results: iperf3 displays real-time transfer rates and outputs a summary at the end. Focus on two figures: measured throughput and retransmission count. If the measured bandwidth is significantly lower than the advertised rate, the bandwidth may be overstated or subject to oversubscription (shared capacity issues). A high retransmission count indicates packet loss on the link, forcing TCP to repeatedly retransmit data. Hardware Benchmarking: bench.sh and YABS

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

If you simply want a quick overview of a new machine's basics in a few minutes, bench.sh is the best choice. It is a classic "one-click" benchmark script in the VPS community; a single command tests everything from system configuration and disk read/write speeds to network speeds connecting to global nodes.

Run the command:

wget -qO- bench.sh | bash

If `wget` is unavailable, you can use `curl` instead:

curl -Lso- bench.sh | bash

bench.sh outputs three main sections: system information (CPU model/core count, AES-NI support, 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 benchmark raw CPU performance; if you need detailed CPU performance data, you should use the tool below.

YABS: An Industry-Standard Comprehensive Benchmark

If you need a standardized benchmark report that allows for direct comparison with VPS users worldwide, YABS (Yet Another Benchmark Script) is currently the most reliable choice. It is maintained by developer masonr and boasts high activity levels on GitHub.

With a single command, YABS performs three tasks in sequence: testing single-core and multi-core CPU performance using Geekbench 6, testing disk read/write speeds across various block sizes using `fio`, and testing network upload/download speeds to global nodes using `iperf3`. A full run takes approximately 10 to 30 minutes.

Run the command:

curl -sL yabs.sh | bash

If the connection fails, you can use the alternative URL:

wget -qO- https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh | bash

Interpreting CPU Benchmark Results: Geekbench 6 is an authoritative, cross-platform benchmarking tool. YABS utilizes its command-line version, producing scores that can be directly compared with those of other VPS users around the world. A single-core score below 400 indicates weak CPU performance, potentially due to severe over-provisioning; 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 Speed: YABS tests read/write speeds across four block sizes—4K, 64K, 512K, and 1M—allowing for the identification of the drive type. Speeds below 200 MB/s indicate an HDD; 200–500 MB/s indicate a standard SATA SSD; 500–3,000 MB/s indicate an NVMe SSD; and speeds exceeding 3,000 MB/s indicate a high-end NVMe RAID array.

Jtti: Providing Reliable Infrastructure for Testing and Validation

Whether you are using MTR to test routing, iperf3 to verify bandwidth, or YABS to assess overall performance, a server with a solid underlying architecture is essential for obtaining reliable test results.

Jtti’s cloud server solutions offer configurations ranging from entry-level to enterprise-grade. All models come standard with enterprise-grade NVMe SSDs, delivering read/write speeds in YABS tests that far surpass those of SATA SSDs. Hong Kong and US nodes connect via premium CN2 GIA lines with optimized direct routing across major carriers; MTR tests show return traffic traversing dedicated 59.43 nodes throughout the route, maintaining a packet loss rate below 0.5% even during evening peak hours. Dedicated bandwidth is standard across the entire lineup, ensuring iperf3 results closely match the advertised specifications without the data distortion caused by "noisy neighbors" competing for bandwidth.

A "same-price renewal" policy guarantees that the renewal cost remains identical to the initial purchase price, ensuring predictable long-term operating costs amidst the anticipated price hikes of 2026.