How to test VPS performance and network speed? The VPS test script collection provides one-click testing solutions, including the Fusion Monster, YABS, bench.sh, UnixBench, IP quality, and streaming media test scripts, which can be used to check the VPS's CPU, memory, disk IO, network speed, latency, packet loss, and IP status.
After buying a new VPS, it is recommended to test it first before deploying important websites. Testing can roughly determine the machine's hardware performance and route performance; if the results differ too much from the merchant's claims, it is also convenient to apply for a refund or change plans in time.
However, script tests can only represent the performance at the time of execution and at the test node. Network speed is affected by time, test node, carrier, route direction, and node load, so a single speed test result cannot be taken as a guarantee of long-term stability.
VPS test scripts
1. Fusion Monster evaluation script: GO version
Fusion Monster is a relatively comprehensive VPS test script that can simultaneously check system information, CPU, memory, hard disk, network, IP quality, and streaming media items. The GO version does not require much environment preparation in advance and supports running as a non-root user, making it more suitable for beginners testing a VPS for the first time.
International users can use the following command:
export noninteractive=true && curl -L https://raw.githubusercontent.com/oneclickvirt/ecs/master/goecs.sh -o goecs.sh && chmod +x goecs.sh && ./goecs.sh install && goecsIf downloading the script from the international network is slow, you can use CDN acceleration:
export noninteractive=true && curl -L https://cdn.spiritlhl.net/https://raw.githubusercontent.com/oneclickvirt/ecs/master/goecs.sh -o goecs.sh && chmod +x goecs.sh && ./goecs.sh install && goecsDomestic users can also use CNB acceleration:
export noninteractive=true && export CN=true && curl -L https://cnb.cool/oneclickvirt/ecs/-/git/raw/main/goecs.sh -o goecs.sh && chmod +x goecs.sh && ./goecs.sh install && goecsScript Open Source Address:https://github.com/oneclickvirt/ecs
2. YABS (Yet Another Benchmark Script)
YABS is a comprehensive test script commonly used by overseas VPS users, mainly testing disk, CPU, memory, and network. It calls tools such as fio and iperf3, does not require manually installing many dependencies, and generally can run without root privileges.
curl -sL https://yabs.sh | bashOr use:
wget -qO- yabs.sh | bashOpen Source Address:https://github.com/masonr/yet-another-bench-script
YABS is more suitable for horizontal comparison of hardware and international bandwidth; if you are mainly concerned about access speed in mainland China, you also need to combine it with the return route, three-network, and different time period tests below, and cannot rely only on a single YABS result.
3. Other commonly used scripts
The following scripts are also relatively common. If Fusion Monster and YABS already meet your needs, you generally do not need to repeat all tests.
bench.sh: system information and multi-location speed tests
wget -qO- bench.sh | bashOr:
curl -Lso- bench.sh | bashUnixBench: comprehensive CPU performance
wget --no-check-certificate https://github.com/teddysun/across/raw/master/unixbench.sh
chmod +x unixbench.sh
./unixbench.shIP Quality Detection
bash <(curl -Ls https://Check.Place) -IOpen Source Address:https://github.com/xykt/IPQuality
Streaming Media Unlock Test
bash <(curl -L -s check.unlock.media)Open Source Address:https://github.com/lmc999/RegionRestrictionCheck
How to Use the Testing Scripts?
First, you need to use an SSH tool to connect to your VPS. Windows users can use Xshell; for specific connection methods, please refer to:Tutorial on Connecting to a VPS Using Xshell。
After a successful connection, pick one of the script commands above, copy and paste it into the SSH window and press Enter, then wait for the script to finish running.
Before testing, note the following points:
- Try to test when the VPS has just been activated and no business has been deployed yet, to avoid website traffic affecting the results.
- First check the script source and command content clearly; do not casually execute scripts of unknown origin on important production servers.
- Different scripts may install temporary dependencies or generate test files; after testing is complete, you can clean them up according to the script's prompts.
- Some network tests take a long time and may also consume a certain amount of traffic; do not run them repeatedly on plans with very little traffic.
- It is recommended to save the test results so that when purchasing VPS from different providers, you can use the same scripts at similar times for comparison.
If you just want to quickly determine whether a VPS is suitable for building a website, you can first run bench.sh to view basic information and multi-location speeds, then run YABS to view disk, CPU, and iperf3 results; if you need to evaluate routes to mainland China, then additionally run three-network, return route, and evening peak tests.
How to Interpret the Test Results?
Disk IO
For disk results, mainly look at read/write speed and IOPS. Different scripts use different test methods, block sizes, and test file locations, so do not directly mix and compare numbers from different scripts.
Generally, you can first make a rough judgment based on the following ranges:
- Sequential read/write above 200 MB/s: usually sufficient for everyday website building
- 100–200 MB/s: generally usable for ordinary websites
- 50–100 MB/s: needs to be judged in combination with price, CPU, and actual use
- Below 50 MB/s: further testing is recommended before running databases and WordPress
If the focus is WordPress or databases, also look at 4K random read/write and IOPS. High sequential read/write does not mean a high-concurrency database will necessarily be fast; test results are also affected by host load and virtualized storage.
Network Speed
For international bandwidth, you can refer to upload and download speeds from multiple locations, but do not look only at the single fastest node. It is recommended to observe at least different directions such as Los Angeles, Asia, and Europe, and record the test time.
If the main users are in mainland China, focus on:
- Whether China Telecom, China Unicom, and China Mobile can all connect
- Whether the outbound and return routes pass through appropriate carrier lines
- Whether latency, packet loss, and jitter are stable
- Whether there is a significant difference between daytime and evening peak
- Whether download speed performs well only at a certain test node
Names such as „CN2“, „three-network premium“, and „optimized routes“ cannot replace actual testing. Different IPs, different data centers, different plans, and even machines activated at different times may not have exactly the same routes.
Latency and packet loss
Lower latency is usually better, but do not look only at the Ping value. If a node has a low Ping value but severe packet loss during evening peak, the actual experience of opening the website may still be very poor.
You can continuously Ping targets of several carriers to observe average latency, maximum latency, and packet loss rate; then use traceroute or mtr to view intermediate routes. Some servers or targets restrict ICMP; no response during testing does not necessarily mean TCP access has failed, so it is best to judge in combination with HTTP downloads or actual website access.
UnixBench and CPU scores
Scores from UnixBench, sysbench, and Geekbench cannot be directly interchanged. Different versions, thread counts, virtualization environments, and CPU models all affect the results.
You can use the score as a reference between the same script and similar configurations:
- Low-scoring machines are suitable for lightweight websites and learning/testing
- Medium scores can run ordinary personal websites
- Higher-scoring machines are more suitable for multiple websites, compilation, or heavier background tasks
Do not decide whether to purchase based on a single benchmark score alone. CPU single-core performance, sustained load performance, memory headroom, disk and network stability all need to be judged together.
Choosing a VPS Based on Test Results
The UnixBench test result is a composite score. Here we mainly combine the results of Rongheguai and YABS to judge whether a VPS is worth purchasing. The standards below can only serve as a reference between the same script and similar configurations; it is not recommended to draw conclusions in isolation from price, purpose, and network route.
Core metric qualification thresholds (2026 reference)
- **Disk Performance**
- Unqualified: 4K random read below 5,000 IOPS
- Qualified: 4K random read 5,000–15,000 IOPS
- Excellent: 4K random read above 15,000 IOPS
- Top-tier: 4K random read above 30,000 IOPS
- **Network Performance**
- Unqualified: download speed below 100 Mbps
- Qualified: download speed 100 Mbps–1 Gbps
- Excellent: download speed above 1 Gbps
- Top-tier: download speed above 5 Gbps
- **CPU Performance**
- Unqualified: sysbench below 600 points
- Qualified: sysbench 600–800 points
- Excellent: sysbench above 800 points
- **Memory Performance**
- Qualified: read/write speed above 5,000 MB/s
- Excellent: read/write speed above 10,000 MB/s
These numbers are not hard standards that all VPSs must meet. For example, low-cost test machines, storage machines, and route-optimized VPSs for domestic access may have different key metrics; when the test node is busy, network speed may also be temporarily low.
Quick Judgment Rules (30-Second Decision Method)
Rule 1: Pause the purchase when key metrics are unqualified.
If the following situations occur, it is recommended to retest at a different time, with a different node, or with a different script first, and not to draw conclusions immediately:
- Disk 4K random read below 5,000 IOPS
- Network download speed below 100 Mbps
- CPU score below 600 points
A low score on a single test does not necessarily mean the entire machine is unusable, but it at least indicates that it is not suitable for directly hosting important business, and the reason needs to be further confirmed.
Rule 2: You can use a simple formula to compare cost-effectiveness.
性价比分数 = 4K随机读IOPS ÷ 月费美元You can roughly refer to the following ranges:
- Below 1,000 points: relatively low cost-effectiveness
- 1,000–2,000 points: medium cost-effectiveness
- 2,000–4,000 points: relatively high cost-effectiveness
- Above 4,000 points: very high cost-effectiveness
This formula is only suitable for comparing machines with similar configurations and similar purposes. It does not account for network routes, IP quality, backups, after-sales support, and stability, and cannot replace a complete purchasing decision.
VPS Selection Guide Based on Practical Cases
Below are the minimal test results from a $6 per month VPS I purchased on Vultr running the Fusion Monster script, for your reference:
CPU单核测试：607分
内存读取：11666.30 MB/s
内存写入：10061.02 MB/s
磁盘4K随机读：32700 IOPS
网络下载：约6700 Mbps
月费：6美元According to the reference standards above, this machine's disk, memory, and network results are all relatively good, and the CPU single-core score just exceeds the reference line. It is suitable for personal blogs, small websites, and general development testing, but you cannot directly assume it is suitable for high-concurrency e-commerce, heavy databases, or game services just because the benchmark scores look good.
Practical application: How to choose your VPS
Scenario 1: Personal blogs and small websites
The focus is on price, stability, backups, and basic network; core metrics reaching a qualified range are usually sufficient.
Scenario 2: Corporate websites, e-commerce, and API services
You need to pay more attention to CPU single-core performance, memory headroom, disk random read/write, database performance, and sustained load; do not just look at the peak bandwidth from a single speed test.
Scenario 3: Databases, games, or high-performance applications
Stronger CPU, memory, and network stability are required. It is best to conduct long-duration stress tests and confirm the provider's traffic, ports, abuse policy, and terms of service. A single benchmark run on a low-cost VPS cannot represent the long-term performance for such applications.
Recommended VPS testing process
If you do not want to spend a long time, you can test in the following order:
- Use bench.sh to confirm CPU, memory, disk capacity, virtualization method, and basic network.
- Use YABS to test disk, CPU, memory, and multiple international iperf3 nodes.
- Use the Fusion Monster to supplement IP quality, three-network nodes, streaming media, and system information.
- For users in mainland China, also test the forward and return routes for China Telecom, China Unicom, and China Mobile.
- Test once during the day and once during the evening peak, observing changes in latency, packet loss, and speed.
- Save the test results, then decide whether to use it long-term based on the website's user region, budget, and purpose.
Test results can only indicate performance at a certain point in time and cannot prove that the provider will be permanently stable. For a formal website, you also need to prepare independent backups, monitoring, and a migration plan. Before purchasing, it is also recommended to check the VPS provider's renewal price, refund policy, traffic limits, IP replacement rules, and terms of service.
If you have not yet decided which VPS to buy, you can first look at this site'sVPS Recommendations, then choose based on budget, user region, and whether you are willing to maintain the server yourself.
Summary
VPS testing scripts can help us quickly understand server performance and network, but no single script can represent the entire real-world experience.
The simplest approach is: first use bench.sh and YABS to check basic performance, then supplement with three-network, return route, packet loss, and evening peak tests based on the user's region. For WordPress websites, you should also judge based on disk IO, memory headroom, and the actual operation of PHP and the database.
Don„t just look at the highest speed from a single speed test, and don“t jump to conclusions just because you see „CN2“ or „premium route“ mentioned. Compare script results, actual access, price, backups, and vendor terms together to more easily choose a VPS that suits you.