日本VPS性能实测方法

一、先定义要测什么：六项指标和它们的取舍

日本VPS性能实测之所以容易被做成「跑分秀」，是因为很多测试只给一个数字，不给判读标准。一个 15 毫秒的延迟数字，如果没有说明是去程还是回程、是白天还是晚高峰、是从哪个城市测的，这个数字就没有决策价值。真正能用来对比和决策的实测，必须同时交代测试项、测试口径、测试时间和判读阈值。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

对面向国内用户的日本节点，值得测的有六项。第一是链路质量，包含往返时延、丢包率和抖动。第二是端口带宽与单连接速率。第三是磁盘性能，分顺序读写和随机读写两个维度。第四是 CPU 算力与调度表现。第五是内存带宽与实际可用量。第六是晚高峰稳定性，也就是在本地晚上八点到十一点这个国内出口最拥挤的时段重测前五项。

这六项不是并列的，它们之间有明确的权重和依赖关系。链路质量决定上限，因为任何应用的数据都要先穿过这条链路；磁盘性能决定很多 Web 应用的体感，因为数据库和缓存的随机写是主要瓶颈；CPU 决定纯计算任务的天花板；而内存则是一个「不够就崩、够了就不影响」的下限约束。新手最容易犯的错是按跑分页的顺序逐项比较，而实际应该先看链路，因为链路差到一定程度时，其他指标测得再漂亮也没有意义。

还有一个前提要先讲清楚：任何一次实测都是一次采样，不是恒定值。同一台机器在不同时段可以差出百分之几十，所以任何单次测试都不足以定论。正确的做法是同一套命令在固定条件下重复执行多次，取中位数，并保留原始数据以便日后对比。

# 固定测试条件：记录时间、节点、网络信息，作为本次结果的元数据
date '+%F %T %Z'
hostnamectl | grep -E 'Model|OS|CPU'
ip -br addr
curl -s https://ipinfo.io/json

# 建议把每次测试输出追加到同一个文件，形成时间序列
mkdir -p ~/vps-bench && cd ~/vps-bench

第一条命令输出的时间戳是全部数据里最重要的元信息。测试报告如果没有时间标注，等于没有报告，因为晚高峰和白天的数据放在一起比较，结论一定是错的。

二、链路质量：延迟、丢包、抖动怎么测

链路测试要分两层。第一层是到日本节点的入口质量，第二层是入口之后的机房内部质量。第一层用 mtr 就能看清楚，第二层要在机器上对网关和公网地址分别测。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

mtr 是 ping 和 traceroute 的结合体，逐跳显示丢包率与时延。用法上有一个关键点：至少要跑够多的轮数，比如二十轮以上，因为短样本很容易把偶发的一两次丢包误判成严重问题。另一个关键点是看终点行与中间跳的关系：如果终点丢包为零但中间某一跳丢包高，那说明丢包是路由层面的抖动，发生在你控制不了的网络段上；如果终点自己也丢包，那才可能是本机或机房出口的问题。

# 1) 逐跳质量：20 轮起步，中途停止用 Ctrl+C
mtr -rwc 20 <target_ip>

# 2) 单点时延与丢包分布
ping -c 30 -i 0.2 <target_ip>

# 3) 在服务器本机测到公网与到网关的延迟，区分「入口」与「机房内」
mtr -rwc 20 8.8.8.8
ip route | head -3      # 看默认网关，mtr 到它

# 4) TCP 握手耗时，排除 ICMP 被限速的干扰
curl -o /dev/null -s -w 'connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://www.baidu.com

第四条命令很重要。有些机房会对 ICMP 限速，导致 ping 看起来延迟很高但实际业务很快。TCP 握手耗时和首字节时间更接近真实体验。所以判读时要两条数据一起看：如果 ping 高但 time_connect 正常，说明只是 ICMP 被限速，业务没受影响；如果两者都高，那才是真的链路慢。

抖动比平均延迟更值得警惕。平均延迟 80 毫秒但很稳的业务体验，往往好过平均 50 毫秒却时好时坏的业务。对网页和 API 来说，抖动主要来自链路上的排队和丢包重传。对有实时交互需求的场景，抖动的影响甚至大于平均时延。

判读标准可以这样定：国内主要城市到日本节点，普通时段往返时延在 60 毫秒以内属于可用，100 毫秒以内可以接受，超过 150 毫秒就要考虑换线路或换机房；终点丢包率稳定为零是底线，晚高峰时段偶发低于 1% 通常在容忍范围，持续高于 2% 就说明这条线路在你的使用时段是不合格的。

三、端口带宽和单连接速率，测的时候要小心

带宽测试最容易出错的两个地方：一是测试源选错，二是把「多连接并发总吞吐」当成「单连接速率」。

延伸对照：zgovps 的公开机型与线路说明，可结合本节的判断标准自行核对。

在服务器上用 curl 下载大文件测出来的是机房到测试源的速率，不是你家宽带到服务器的速度。真正的端到端体验必须在客户端侧测，或者至少在「服务器到国内某个可达节点」的路径上测。

另一个常见错误是用多线程下载工具测出总带宽，然后拿这个数字去对比单连接体验。多连接能跑满端口，但每个用户实际拿到的是总带宽除以连接数。判断「我的站点访问速度」应该看单连接速率，判断「我能不能做下载站」才看多连接总吞吐。

# 1) 单连接下载速率（从客户端侧执行更有意义）
curl -o /dev/null -s -w 'speed:%{speed_download} B/s  time:%{time_total}s\n' https://speed.test/file.iso

# 2) 多连接总吞吐（iperf3 需要对端配合）
iperf3 -c <peer> -t 30 -P 4 -R          # 4 条并发反向流
iperf3 -c <peer> -t 30 -P 1              # 单流对照

# 3) 观察测试时是否出现丢包与重传
ss -ti dst <peer> | grep -E 'rtt|retrans|cwnd'

# 4) 用 iperf3 反向测试服务器上传能力
iperf3 -c <peer> -t 30 -R -P 8

第三条命令是带宽测试的诊断关键。正常情况下 retrans 计数应该很小；如果它持续增长，说明链路有丢包且 TCP 在不断重传，这时候你测出来的带宽数字其实是「丢包后的降级吞吐」，而不是线路的真实能力。同理，cwnd（拥塞窗口）如果很小，说明 TCP 认为这条路径很拥堵。遇到这种情况的处理顺序是：先换测试源排除本地问题，再看是不是测试时段处在高峰，最后考虑这条线路本身带宽不足或者被 QoS 限速。

还有一个隐藏变量是「端口速率 vs 实际速率」的折扣。商家标注 1 Gbps 端口时，实际能跑到 700 兆到 900 兆就算正常，因为存在协议开销和突发额度限制。如果只能跑到标注值的三分之一以下，就该向商家确认是否有 QoS 策略。

四、磁盘 IOPS 怎么测：NVMe 和 SATA 的差距在哪

磁盘性能对 Web 业务的影响常常被低估。数据库的每一次索引更新、Redis 的每一次过期回收、Node.js 的每一次模块加载，都是小块随机读写，而这正是 SATA SSD 和 NVMe 差距最大的地方。在 4 K 随机写上，SATA 阵列上的虚拟盘常见值只有几千 IOPS，NVMe 可以到几万甚至十几万，相差一个数量级。

延伸对照：恒创科技 的公开机型与线路说明，可结合本节的判断标准自行核对。

测试磁盘有两个必须知道的细节。第一，测试前要清缓存，否则测的是缓存而不是磁盘。第二，测试目录必须是真实的数据盘，不能是临时挂载的内存盘或者被优化过的系统盘——很多商家会把系统盘放在内存盘上以加速，你在那里测出的数字跟真实存储完全无关。

# 1) 确认磁盘类型和挂载点，别在 tmpfs / ramdisk 上测
lsblk -f
df -hT
mount | grep -E 'tmpfs|ram'

# 2) 4K 随机读写（最接近数据库场景）
fio --name=randrw --ioengine=libaio --direct=1 --filename=/var/tmp/fio.tst \
    --size=1G --rw=randrw --bs=4k --iodepth=32 --runtime=60 --group_reporting

# 3) 顺序读写（看大文件传输与备份场景）
fio --name=seq --ioengine=libaio --direct=1 --filename=/var/tmp/fio.tst \
    --size=1G --rw=read --bs=1M --iodepth=8 --runtime=30
fio --name=seqw --ioengine=libaio --direct=1 --filename=/var/tmp/fio.tst \
    --size=1G --rw=write --bs=1M --iodepth=8 --runtime=30

# 4) 观察实际业务期间的 IO 等待
iostat -x 1 10

判读标准是这样的：4 K 随机写的 IOPS 在 1000 以下，说明这块盘基本是 SATA 级别且可能还被限速；3000 到 8000 属于普通 SSD 水平；一万以上才可以认为跑在 NVMe 上。另外一定要看 clat（平均完成延迟），IOPS 高但 clat 也很高（比如超过 20 毫秒）意味着队列在排队，实际业务会感觉到卡；IOPS 和 clat 都健康的组合才算合格。

第四条命令里的 %util 和 await 是业务视角的指标。%util 持续接近 100% 表示磁盘长期满负荷，await 超过 50 毫秒意味着单次 IO 请求要等半个多才能返回。这两个数字如果在业务高峰时爆表，就说明该换磁盘类型或减少随机写，而不是加 CPU。

磁盘测试还有两个容易忽略的前提。第一是测试文件要落在真实数据盘上，并且用 --direct=1 绕过操作系统页缓存，否则测出来的是内存的速度而不是磁盘的速度。第二是测试期间不要同时跑其他业务，磁盘是共享资源，后台跑着的备份、数据库刷盘都会把数字拉低，导致把别人的负载误判成自己的磁盘性能差。跑之前先用 iostat -x 1 3 确认当前没有 IO 活动，是最省事的做法。

如果商家明确标注了磁盘类型和 IOPS 配额，你的实测数字就应该落在这个区间内而不是一个笼统的高数值。标注 NVMe 但实测只有三千 IOPS，说明配额被限了或者挂的是 SATA 阵列；标注不限 IOPS 但实测长期卡在一千上下，那多半是整台机器在超售，磁盘资源被多个租户分摊。把这两种情况区分清楚，对应的处置方式完全不同：前者找商家确认配额口径，后者是换商家的信号。

五、CPU 与内存：算力跑分和真实负载的关系

CPU 跑分的常见误区是只看整数成绩。整数跑分反映的是纯计算能力，但你买的机器是共享宿主机上的虚拟核，真实的性能还受 CPU 频率、宿主机是否超售、以及你的虚拟核是否被调度到同一物理核的两个超线程上影响。所以同一个跑分分数在不同机器、不同时间可以差百分之几十。

延伸对照：景文互联 的公开机型与线路说明，可结合本节的判断标准自行核对。

跑分之外，更应该看的是「负载下的表现」。用 stress-ng 之类工具把 CPU 压满，同时观察有没有异常，是识别宿主机超售最直接的办法。

# 1) 整数与浮点跑分，作为横向对比的基准
sysbench cpu --cpu-max-time=20 --threads=2 run
sysbench memory --memory-max-size=2048 --threads=2 run

# 2) 压测中观察调度与抢占（steal 明显偏高说明宿主机在抢你的 CPU）
vmstat 1 10
# 重点看 st 这一列：持续 > 5% 说明超售，持续 > 20% 则性能不可预测

# 3) 检查超线程与实际可用核
lscpu | grep -E 'Model name|CPU\(s\)|Thread|Core|MHz'
cat /sys/fs/cgroup/cpu.max 2>/dev/null
cat /sys/fs/cgroup/cpu.stat 2>/dev/null | head -5

# 4) 内存实际可用量与回收压力
free -m
cat /proc/meminfo | grep -E 'MemAvailable|Dirty|Writeback'

第二条命令里的 st（steal time）列是判断超售的关键指标，它表示 hypervisor 抢走的时间。st 长期为零说明宿主机资源充足；st 在压力测试期间跳到百分之十以上，说明你的虚拟核和其他租户在抢同一批物理核；超过百分之二十就意味着你买的配置数字是「名义上的」，实际性能完全取决于运气。

第三条命令里 cpu.max 这一项值得单独看。有些服务商给的是 cgroup 层面的 CPU 配额，比如限制在 200% 意味着两核封顶，即使宿主机空闲你也用不了更多。这一点在套餐表上通常不写，但直接决定你的实际算力。

内存测试要分清「可用量」和「带宽」这两个维度。free -m 里的 available 才是你能真正分配给新进程的量，free 字段本身在现代内核里参考价值不大。另外要留意内存回收压力：如果 Dirty 和 Writeback 长期累积，说明内存不足导致大量数据被推迟写回磁盘，业务上表现为随机延迟尖刺。

六、晚高峰实测：为什么要在八点到十一点重测一遍

白天测出来的数据好看不算数。国内晚高峰通常指晚上八点到十一点，这段时间三大运营商的国际出口和跨境链路都处于拥堵状态，丢包和排队延迟显著上升。很多商家在宣传页上放的测速截图都是白天在机房内部测的，和你实际感受到的体验关系不大。

延伸对照：backwaves 的公开机型与线路说明，可结合本节的判断标准自行核对。

晚高峰实测的核心不是「测出一个更差的数字」，而是「对比出这条线路在拥堵时的退化幅度」。同一家商家的不同线路、同一个商家的不同机房，在晚高峰的表现可能天差地别。

# 晚高峰复测脚本：一次跑完全部关键项，输出带时间戳的记录
cat > ~/vps-bench/peak.sh <<'EOF'
#!/usr/bin/env bash
TS=$(date '+%F-%H%M')
OUT=~/vps-bench/${TS}.log
{
  echo "===== 晚高峰复测 $TS ====="
  echo "--- mtr 20 轮 ---";        mtr -rwc 20 223.5.5.5
  echo "--- ping 50 次 ---";       ping -c 50 -i 0.2 223.5.5.5
  echo "--- TCP 握手 ---";         curl -o /dev/null -s -w 'connect:%{time_connect} ttfb:%{time_starttransfer}\n' https://www.baidu.com
  echo "--- 磁盘 4K 随机写 ---";   fio --name=r --ioengine=libaio --direct=1 --filename=/var/tmp/fio.tst --size=512M --rw=randrw --bs=4k --iodepth=32 --runtime=20 --group_reporting 2>/dev/null | tail -12
  echo "--- CPU ---";              uptime; vmstat 1 5 | tail -3
} | tee -a "$OUT"
EOF
chmod +x ~/vps-bench/peak.sh

脚本里最有用的是同时记录了 mtr、ping 和 TCP 握手三组数据。如果晚高峰 mtr 显示中间某跳大量丢包，而终点丢包为零、TCP 握手时间也还正常，那么问题在链路上游而不是这台机器，换机器解决不了，只能换线路或换机房。反过来，如果 TCP 握手时间在晚高峰明显变长且终点也有丢包，那才可能是机器本身或机房出口的问题。

对比时用中位数而不是平均值。一天跑三次，取中位数那次的结果做基准，这个中位数对偶发尖刺不敏感，能反映这条线路的「常态表现」。

还有一点：晚高峰实测要固定测点和时段。不要今天从电信测、明天从联通测，也不要白天测完当天晚上就下结论。测点不同，运营商路由就不同，结论没有可比性。

七、异常定位：延迟高、丢包、跑分低怎么一步步查

拿到异常数据后不要立刻找商家，先按顺序排查，否则很容易把本地问题当成商家的锅。排查顺序是：本地网络、你的客户端、宿主机资源争抢、机房出口、跨境链路。前面几项在自己这边就能排除，而且成本最低。

延伸对照：digitalvirt 的公开机型与线路说明，可结合本节的判断标准自行核对。

先看延迟高的情况。第一步排除本地问题：ping 一下网关，看延迟是不是正常（有线宽带一般是 1 毫秒以内）；第二步在服务器上 ping 公网地址，看机房内部是否正常；第三步对比 mtr 的每一跳，找到延迟跳升的那一跳。判读的关键是：如果延迟从某一跳开始陡然增加且后续持续高位，问题就在那一跳之后的网络，与你的机器无关。

丢包的情况稍微复杂，因为它可能是「真丢包」也可能是「ICMP 限速导致的假丢包」。区分方法是用 TCP 层面的观测：如果在 mtr 显示丢包的同时，ss -ti 的 retrans 计数没有同步增长，那基本是 ICMP 被限速，业务流量没受影响；如果 retrans 在涨，那就是真的丢包，必须处理。

跑分低的情况，先确认 st（steal time）是否被抢占，再看 cpu.max 是否有 cgroup 配额限制，最后看宿主机是否存在其他租户的高负载。这三步能解释绝大多数「配置写的是 4 核但跑分只有 2 核水平」的现象。

# 逐层定位延迟：从本地网关开始逐跳向服务器走
traceroute -T -p 443 <server_ip>
mtr -T -P 443 -rwc 20 <server_ip>

# 丢包真伪判定：看 TCP 重传是否同步增长
ss -tin dst <server_ip> | grep -E 'retrans|rtt'

# 宿主机争抢：压测时看 steal
stress-ng --cpu 2 --timeout 60s --metrics-brief &
vmstat 1 20 | awk 'NR>2{print "steal="$16, "idle="$15}'

# 系统层面：是否有本机进程在抢资源
iotop -oPa 2>/dev/null | head -10
mpstat -P ALL 1 5

第四条命令的输出里，如果 steal 那一列在压力期间稳定在百分之十以上，基本可以断定是宿主机超售，此时把工单发给商家并附上这段输出，比口头描述「很卡」有效得多。给商家反馈时永远带上原始数据和时间戳，这是让对方快速定位问题的关键。

八、把实测结果变成可比较的评分表

单看一堆数字很难决策，把不同机器的实测结果归一化成一张对比表，判断会快很多。做法是为每项指标设定一个「及格线」和一个「优秀线」，然后把实测值映射到 0 到 100 的分数。

延伸对照：hostkvm 的公开机型与线路说明，可结合本节的判断标准自行核对。

日本节点的常用参考线可以这样定：往返时延 60 毫秒得 60 分、40 毫秒得 80 分、25 毫秒得 100 分；晚高峰终点丢包 0% 得 100 分、1% 得 70 分、3% 得 40 分；单连接速率 10 MB/s 得 60 分、50 MB/s 得 85 分、100 MB/s 得 100 分；4 K 随机写 3000 IOPS 得 60 分、10000 IOPS 得 85 分、30000 IOPS 得 100 分；CPU 跑分同档位机器中位数得 60 分、高 20% 得 85 分、高 50% 得 100 分。

# 用一个简单的脚本把多次测试的原始输出汇总成 CSV，便于横向对比
cat > ~/vps-bench/score.sh <<'EOF'
#!/usr/bin/env bash
# 用法: ./score.sh <label> <logfile>
LABEL=$1; LOG=$2
LAT=$(grep -oE 'rtt [0-9.]+/[0-9.]+' "$LOG" | head -1 | awk -F'/' '{print $2}')
LOSS=$(grep -oE 'Loss%[^0-9]*[0-9.]+' "$LOG" | tail -1 | grep -oE '[0-9.]+')
IOPS=$(grep -oE 'IOPS=[0-9.k]+' "$LOG" | tail -1 | cut -d= -f2)
echo "${LABEL},${LAT:-na},${LOSS:-na},${IOPS:-na}" | tee -a ~/vps-bench/score.csv
EOF
chmod +x ~/vps-bench/score.sh

除了绝对分数，还要看「短板分」。一台延迟极好但随机写只有 1500 IOPS 的机器，对跑 WordPress 的站点来说比一台延迟平庸但磁盘是 NVMe 的机器更差，因为瓶颈出现在你最关键的路径上。所以最终决策应该看短板，而不是看加权总分。

表格之外，还有三件事建议一并记录：测试时的服务器价格、测试时是否处于商家的促销期、以及是否有多个备用机房。这样三个月后再看这张表，你能同时看清「性能变化」和「性价比变化」。

九、换机器还是继续用：拿数据做决定

实测的最终目的是决策：继续用这台，还是换。判断依据不是单次得分，而是三个具体问题的答案。

延伸对照：vollcloud 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一问，业务瓶颈到底在哪一层。如果你的业务是静态内容分发，链路质量决定一切，磁盘和 CPU 的分数可以忽略；如果你的业务是数据库密集型，磁盘随机写决定一切；如果你的业务是 API 高频调用，链路时延和抖动的权重最高。用 iostat、vmstat 和访问日志交叉确认瓶颈层，再去看对应的那项指标是否不达标。

第二问，问题是否可归因于你的配置。跑分低但 st 为零、cpu.max 没有限制，那是宿主机性能差或者整机超售，跟你买几核无关，升配也救不了，只能换商家。延迟高但晚高峰不抖、白天也高，那通常是线路问题。丢包集中在晚高峰，那是链路拥塞。磁盘慢且 await 很高，那才是磁盘本身或者套餐给了 SATA。

第三问，问题的代价和收益是否匹配。晚高峰丢包 2% 带来的额外加载时间，如果你的月访问量只有几千次，实际损失很小，不值得为了这个换机器；而对一个大流量电商站，同样的丢包造成的转化损失可能足够覆盖全年服务器成本。这道题要用数字算，不能凭感觉。

# 定位瓶颈层：三个命令交叉看
iostat -x 1 10      # 磁盘：%util 与 await
vmstat 1 10        # 系统：wa 高=磁盘瓶颈, us 高=CPU 瓶颈, si/so 高=内存瓶颈
ss -s               # 网络：连接数与重传情况
tail -n 3000 /var/log/nginx/access.log | \
  awk '{print $NF}' | sort | uniq -c | sort -rn | head   # 后端响应码分布

第一条命令的判读标准：wa 长期超过 20% 是磁盘瓶颈，us 超过 80% 是 CPU 瓶颈，si 和 so 非零说明内存不足在换页。第二条命令看的是连接数与重传，重传比例高说明链路有丢包。第四条命令的输出里，如果 502 和 504 占比高，说明后端处理超时，这通常指向 CPU 或内存不足，而不是网络问题。

还有一个务实的做法：先问商家要一次「换机」而不是「退款」。同一家商家的另一台机器、另一个机房，可能表现完全不同。很多商家在工单里会提供换机选项，这比你自己反复折腾要高效得多，也比直接退款保留了服务连续性。

十、常见问题

日本VPS性能实测应该测哪几项才够用？ 至少测六项：往返时延与丢包、单连接下载速率、磁盘 4 K 随机写 IOPS、CPU 跑分与 steal time、内存实际可用量，以及晚高峰复测。前三项覆盖大部分用户的真实感知，后三项区分「参数达标」和「实际体验」。如果时间有限，最少要测 mtr 逐跳质量、fio 随机写、以及晚高峰八点到十一点的那一次复测，因为这三项最能暴露虚标配置和线路劣化。

ping 延迟 200 毫秒是不是太慢了？ 单独看这个数字无法定论，要先确认三件事。第一，测的是去程还是回程，国内访问日本常见的组合是去程几十毫秒、回程一百多毫秒，如果商家优化了其中一个方向，另一个方向慢是正常的。第二，是否是 ICMP 限速，用 TCP 握手耗时对照一下，如果 time_connect 正常而 ping 高，说明只是 ICMP 被限速，业务不受影响。第三，是不是在晚高峰测的，平时四十毫秒晚高峰一百八十毫秒属于跨境链路正常波动。对国内用户来说，超过 150 毫秒的稳定往返时延才会明显影响交互体验。

fio 测出来的 IOPS 只有一千，是不是被限速了？ 大概率是。SATA SSD 的 4 K 随机写在几千 IOPS 量级，NVMe 在几万量级，一千这个数值明显低于 SATA 的常见水平。但先排除三个干扰因素：测试目录是不是落在内存盘或被优化过的系统盘上（df -hT 看文件系统类型）、测试文件是否太小导致全部命中缓存（用 --direct=1 绕过缓存、--size=1G）、是否被 cgroup 的 blkio 限制（cat /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device）。排除之后仍是一千左右，就可以带数据向商家确认 IOPS 配额。

测出来性能不错，为什么实际用起来还是卡？ 因为实测覆盖的是网络与硬件，而实际卡顿经常出现在应用层。最常见的三种情况：一是应用自身的并发配置不足，比如 PHP-FPM 的 worker 数量太少，请求在排队；二是应用没有做缓存，数据库被直接压在磁盘上；三是日志和监控本身在刷 IO。用 vmstat 1 10 看 wa 是不是高、用 ss -s 看连接堆积在哪一层、用 tail 看访问日志的响应码分布，就能定位到具体是哪一层的问题。硬件没问题而应用慢，说明瓶颈在配置而不在机器。

晚高峰实测应该在哪几个时间点做？ 至少覆盖三个时点：晚高峰起点八点左右、高峰中段九点半到十点、以及高峰尾声十一点。用这三个点分别记录一次数据，取中位数作为常态水平。测点时间要固定，不要今天测八点、明天测十点。另一个要点是测试源固定，用同一条宽带、同一个城市、同一个运营商，不要在移动和电信之间来回换，路由不同数据不可比。

实测数据可以拿来跟商家谈退款或换机吗？ 可以，而且比口头描述有效得多。给出证据的标准是四件套：完整命令和原始输出、精确到分钟的时间戳、以及能说明问题的判断依据。比如 mtr 显示晚高峰终点持续丢包 3%，同时说明这直接影响业务，请商家核对出口线路；或者 fio 显示 4 K 随机写稳定在 1200 IOPS，同时给出同套餐在其他商家的实测数值作为参照。退款诉求要放在实测结论之后，先给商家一次排查和换机的机会，这样后续争议时你的诉求更站得住脚。