美国服务器性能不能靠一次 ping 或套餐标称带宽判断。更可靠的方法是先把业务负载拆成请求量、并发数、请求类型、数据大小、峰值时段和增长率，再在固定测试节点上分时段采集网络延迟、存储 IOPS 与实际吞吐，最后将结果与业务可接受的延迟和容量余量对应起来。

测试时应保持服务器、测试节点、协议、时间口径和命令参数一致。延迟适合高频轻量采样，带宽适合在固定窗口重复测试，IOPS 则应在专用测试盘或业务低峰期进行，不能把不同环境下的一组零散数字直接横向比较。

先确定业务负载和测试目标

容量规划的起点不是“这台美国服务器能跑多少”，而是业务在什么负载下需要多少资源。至少应记录以下变量：

• 峰值请求速率：每秒请求数或每分钟请求数。
• 并发请求数：同时保持连接或正在处理的请求数量。
• 请求类型：静态文件、接口请求、文件上传、文件下载或数据库读写。
• 单次数据量：平均响应大小、较大响应大小以及上传和下载方向。
• 峰值时间：按业务所在时区记录，不要直接套用某个固定的北京时间或美国当地时间。
• 数据增长：存储容量、日志量、文件数量和读写频率的增长率。
• 可接受的服务目标：例如接口的 p95 延迟上限、允许的错误率和可接受的带宽余量。

这些变量决定测试重点：

如果业务请求速率为 R，平均单次响应大小为 B 字节，则网络有效需求可以先按以下关系估算：

网络有效吞吐 ≈ R × B × 8

实际还要加入协议头、TLS、重传、并发连接和峰值波动带来的开销。这个公式只能帮助确定测试规模，不能直接代替实测结果。

建立可复现的测试环境

同一台美国服务器在不同测试节点、协议和时间段下，结果可能明显不同。因此每组数据都要绑定完整的测试环境。

需要固定和记录的条件

测试记录至少包含：

• 服务器标识、操作系统版本和公网地址。
• 测试节点的网络环境、出口地址和所在业务入口位置。
• 测试时间、时区和是否处于业务高峰。
• IPv4 或 IPv6，不能把两个协议的结果混在同一组数据中。
• 测试域名或 IP、端口、URL 路径和是否经过 TLS。
• 测试工具及版本，例如 ping、curl、iperf3、fio。
• 测试参数，包括并发数、块大小、队列深度、持续时间和数据文件大小。
• 测试期间的 CPU、内存、磁盘利用率和是否存在其他任务。
• 服务器是否有业务流量、备份、日志轮转或维护操作。

可以在测试前保存基础信息：

date --iso-8601=seconds
uname -a
df -hT
ip -br address

命令输出应与测试结果放在同一份记录中。若服务器正在进行备份、批量导入、镜像更新或其他高负载任务，应单独标记，不要将这组结果当作常态性能。

设计分时段采样

分时段的关键不是把一天机械地分成几个时间段，而是覆盖业务真实的低峰、常态和峰值。建议采用以下方法：

1. 先根据访问日志或监控确定业务峰值时段。
2. 将测试时间统一转换到一个固定时区，并在记录中明确标注。
3. 如果尚未掌握峰值规律，可以按小时采集轻量延迟数据，再根据结果划分重点时段。
4. 每个时段使用相同测试节点、相同参数和相同测试顺序。
5. 轻量延迟可以高频采样，带宽和 IOPS 测试应降低频率，避免测试本身制造拥塞。
6. 至少覆盖一个完整业务周期；如果工作日和周末差异明显，应分别记录。

一种可执行的采样安排如下：

同一时段内不要同时运行 iperf3 和 fio。带宽测试会占用网络和 CPU，IOPS 测试会增加磁盘队列，两者并行会使结果失去可比性。

延迟怎么测：从网络往返到真实请求

延迟至少要分为三层观察：

• ICMP 往返时间：了解基础网络往返情况。
• TCP 建连时间：反映建立连接所需的时间。
• HTTPS 请求时间：更接近业务实际体验，包括连接、TLS 和服务器处理。

ICMP 延迟

在固定测试节点执行：

ping -4 -c 60 -i 1 <服务器IP>

每组采样应记录最小值、平均值、最大值、标准差或抖动信息以及丢包率。ping 被限制或禁用时，不能据此直接判断业务不可用，应改用 TCP 或 HTTPS 测试。

如果环境安装了 mtr，可以补充观察路径上的变化：

mtr -4 -rwzc 100 <服务器IP>

中间节点显示丢包，不一定代表最终服务器丢包。应优先看最终目标一跳的丢包和延迟，并结合 TCP、HTTPS 结果判断。

TCP 和 HTTPS 延迟

对业务域名或专用健康检查地址进行测试：

curl -4 -sS -o /dev/null \
  --connect-timeout 10 \
  --max-time 30 \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
  'https://<测试域名>/<健康检查路径>'

如需连续采样，可以使用固定间隔循环执行：

for i in $(seq 1 60); do
  printf '%s ' "$(date --iso-8601=seconds)"
  curl -4 -sS -o /dev/null \
    --connect-timeout 10 \
    --max-time 30 \
    -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
    'https://<测试域名>/<健康检查路径>'
  sleep 1
done

测试路径应尽量固定。若健康检查接口会访问数据库、读取缓存或触发复杂业务逻辑，要单独标注；否则测到的不是纯网络延迟。

延迟结果应该看什么

不要只看平均值，应至少统计：

• p50：典型请求的中位数。
• p95：大多数请求的高位延迟。
• p99：少量慢请求和尖峰情况。
• 丢包率、超时数和 HTTP 错误数。
• DNS、TCP 建连、TLS、首字节和总耗时的分项数据。

判断方式可以按以下逻辑进行：

• ICMP 延迟较高，但 TCP 和 HTTPS 稳定：可能是 ICMP 优先级较低，不能直接认定业务慢。
• TCP 建连明显变慢：重点查看连接数、服务器资源和网络拥塞。
• 建连正常但 TTFB 升高：更可能与应用处理、进程排队、缓存或存储读取有关。
• p50 正常而 p95、p99 明显升高：说明平均体验尚可，但峰值请求或部分连接存在排队、重传或资源争用。
• 丢包和超时只在某些时段出现：应保留分时段数据，不要用全天平均值掩盖周期性问题。

IOPS 怎么测：区分读写、块大小和队列深度

IOPS 不是一个脱离条件的固定指标。随机读、随机写、顺序读、顺序写使用不同的块大小、并发数和队列深度，结果不能混为一谈。

测试前的安全条件

fio 的写入测试可能覆盖指定测试文件中的内容，并产生明显磁盘负载。执行前必须满足：

• 使用专用测试盘、专用挂载点或确认可以覆盖的测试文件。
• 不要把生产数据库文件、日志目录或正在使用的业务文件作为 --filename。
• 如果测试路径不是可丢弃数据，应先完成备份，并确认业务低峰和影响范围。
• 预留足够空间，测试文件大小要能覆盖实际测试需求。
• 测试期间观察磁盘利用率、延迟和业务错误。
• 测试完成后，通过已批准的存储清理流程处理测试文件；清理前再次核对路径，避免误删业务数据。

先确认测试路径：

df -hT /mnt/benchmark
ls -ld /mnt/benchmark

如果路径为空闲测试卷，可以先准备一个测试文件。下面的写入命令只适用于已确认的专用测试路径：

fio --name=prepare \
  --filename=/mnt/benchmark/fio-testfile \
  --size=10G \
  --rw=write \
  --bs=1M \
  --iodepth=16 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --direct=1 \
  --group_reporting

其中 10G、60 秒、16 队列深度只是测试模板，实际应根据测试盘空间、业务影响和目标负载调整，不能当作美国服务器的性能结论。

分别测试常见 I/O 模式

顺序读：

fio --name=seqread \
  --filename=/mnt/benchmark/fio-testfile \
  --rw=read \
  --bs=1M \
  --iodepth=16 \
  --numjobs=1 \
  --runtime=60 \
  --time_based \
  --direct=1 \
  --group_reporting

随机读：

fio --name=randread \
  --filename=/mnt/benchmark/fio-testfile \
  --rw=randread \
  --bs=4k \
  --iodepth=32 \
  --numjobs=4 \
  --runtime=60 \
  --time_based \
  --direct=1 \
  --group_reporting

随机写：

fio --name=randwrite \
  --filename=/mnt/benchmark/fio-testfile \
  --rw=randwrite \
  --bs=4k \
  --iodepth=32 \
  --numjobs=4 \
  --runtime=60 \
  --time_based \
  --direct=1 \
  --group_reporting

测试结果应记录 IOPS、带宽、平均延迟以及完成延迟的高分位数。--direct=1 用于尽量绕过操作系统页缓存，但仍不能把 fio 结果等同于数据库或文件服务的实际表现。

同时观察系统资源：

iostat -xz 1

重点关注：

• 读和写是否需要分别满足业务需求。
• IOPS 增加时，延迟是否同步快速上升。
• 磁盘利用率是否长期接近饱和。
• 多个 numjobs 或更高 iodepth 带来的吞吐提升，是否以不可接受的延迟为代价。
• 服务器 CPU 是否先于存储达到瓶颈。

如果低队列深度下延迟稳定，而提高队列深度后 IOPS 不再增长、延迟明显升高，通常说明已经接近该测试条件下的有效容量。此时不能只引用最高 IOPS，而应采用满足业务延迟目标时的 IOPS 作为可用容量。

带宽怎么测：分别验证方向和并发

带宽测试必须使用获得授权的对端。对端可以是受控测试节点或明确允许进行吞吐测试的服务，不应随意向公共地址持续发起大流量。

在对端启动 iperf3：

iperf3 -s

从测试节点向美国服务器发送数据：

iperf3 -c <服务器IP> -P 1 -t 30 -O 5 -J

使用多个 TCP 流测试并发连接下的吞吐：

iperf3 -c <服务器IP> -P 4 -t 30 -O 5 -J

测试反向方向：

iperf3 -c <服务器IP> -P 1 -t 30 -O 5 -R -J

这里的 -P 表示并行流数量，-t 表示持续时间，-O 用于忽略刚开始阶段的预热时间，-R 用于反向传输。所有时段都要使用相同参数，否则无法判断差异来自时间变化还是测试设置变化。

带宽测试需要记录：

• 单连接和多连接吞吐。
• 上行和下行方向。
• 测试开始后的稳定吞吐，而不是瞬时峰值。
• TCP 重传、连接失败和测试期间的 CPU 使用率。
• 是否受到业务流量、测试节点出口或对端能力限制。

如果单连接吞吐低、多连接明显提升，可能存在单连接窗口、并发处理或协议参数限制；如果多连接也无法提升，并且服务器出口或 CPU 使用率较高，才更接近资源上限。若 iperf3 结果正常，但真实 HTTPS 下载速度较低，应继续检查 TLS、应用进程、磁盘读取、文件大小和连接复用情况。

还要注意单位换算：带宽通常以 bit/s 表示，文件传输速度常以 Byte/s 表示，二者换算时需要除以 8，并考虑协议开销。

用统一表格保存每次结果

建议每次测试都使用相同字段，避免只保存一个“最好成绩”：

每个时段最好重复多次，并保留原始输出。平均值可以用于概览，但容量判断应优先参考稳定区间和高分位延迟。

结合负载判断瓶颈

测试结果应与业务负载同时分析，而不是单独比较数字。

延迟高，IOPS 和带宽正常

如果网络基础延迟、TCP 建连或 TTFB 在峰值时段升高，而 IOPS 和带宽仍有余量，应检查连接并发、应用排队、CPU、内存回收和请求处理时间。此时直接增加磁盘吞吐未必有效。

IOPS 低或延迟高，网络正常

如果随机读写的 IOPS 达不到业务需求，并且磁盘利用率或 I/O 延迟在峰值明显上升，存储更可能是瓶颈。要分别看读和写，不能用顺序读带宽替代随机读写能力。

带宽低，延迟和 IOPS 正常

如果 iperf3 或真实大文件传输在多个时段都受限，而服务器磁盘和 CPU 没有同步升高，应核对测试对端、传输方向、并发流数和出口使用情况。单连接结果不能代表多连接业务，反之亦然。

只有某个时段恶化

将峰值时段与低峰时段的 p95、p99、IOPS、吞吐和服务器资源放在一起比较。如果只有峰值期间恶化，应估算峰值增长后的余量，而不是采用低峰成绩作为容量依据。

把测试结果换算成容量余量

对于网络，可使用实测峰值请求量和响应数据量估算未来需求：

未来网络需求
≈ 当前峰值请求率 × 平均响应字节数 × 8 × 增长系数

其中增长系数应来自业务增长率和峰值放大情况。例如，若请求量每个规划周期增长率为 g，经过 n 个周期后的请求量可按以下关系推演：

未来请求量 = 当前请求量 × (1 + g)^n

对于存储 IOPS，应拆分读和写：

总读 IOPS ≈ 读请求率 × 每次请求产生的存储读操作数
总写 IOPS ≈ 写请求率 × 每次请求产生的存储写操作数

每次请求产生多少次实际 I/O，不能凭经验填写，应通过应用指标、数据库统计或业务压测记录获得。

可用容量不要直接取测试中出现过的最高值，而应定义为“在目标 p95 或 p99 延迟仍满足要求时的稳定容量”。容量余量可以表示为：

容量余量 = 1 - 峰值实际需求 / 可接受的稳定容量

如果业务同时受网络、IOPS 和延迟约束，应分别计算三类余量，最终以最小余量作为扩容参考。某一项资源看起来富余，并不能抵消另一项资源已经饱和的影响。

复测条件和失败处理

需要复测的情况

出现以下变化时，原有结果不应继续直接引用：

• 测试节点、出口地址、域名解析或 IP 协议发生变化。
• 服务器系统、磁盘挂载、应用版本或配置发生变化。
• 业务请求量、响应大小、缓存命中率或并发模型发生变化。
• 测试时间从低峰变为峰值，或时区记录不一致。
• fio 的块大小、队列深度、并发数或测试文件大小改变。
• iperf3 的方向、并行流数或对端改变。
• 网络、存储或服务器正在进行维护。

复测时应保持旧参数不变，先复制一组基线数据，再只改变一个变量。例如先保持时间、节点和协议一致，仅增加并发流数；不要同时更换测试节点和带宽参数。

常见失败情况

• ping 无响应：先用 TCP 或 HTTPS 验证，不要直接判定服务器不可达。
• curl 超时：记录 DNS、TCP、TLS 和 TTFB 分项，判断卡在哪一步。
• iperf3 连接被拒绝：检查对端是否启动、测试端口是否获得授权，不能未经确认就修改防火墙。
• fio 无法创建文件：先检查路径、权限和剩余空间，确认没有指向业务盘，不要直接扩大权限。
• fio 结果波动很大：查看测试文件是否位于缓存、是否有其他 I/O、测试盘是否正在执行后台任务。
• 带宽测试影响线上请求：立即停止高流量测试，保留当时的时间和资源记录，并改到隔离环境或维护窗口复测。

用监控阈值确定扩容触发点

扩容阈值应从业务目标反推，而不是套用一个固定百分比。可以按以下步骤建立规则：

1. 选定业务最关心的指标，例如 HTTPS p95、HTTPS p99、读写 IOPS、网络吞吐或错误率。
2. 找到满足目标延迟时的稳定容量，作为可接受容量上限。
3. 记录峰值需求及其增长率，计算未来规划周期内的需求。
4. 为每类资源分别设置观察阈值、预警阈值和扩容阈值。
5. 要求阈值连续多个采样周期成立，避免一次性尖峰触发错误扩容。
6. 如果 SLO 已被突破，即使平均资源利用率不高，也应优先处理延迟和排队问题。

较稳妥的触发条件通常包括：

• 峰值时段的 p95 或 p99 连续超过业务目标。
• 网络、IOPS 或存储延迟达到可接受稳定容量，并且未来增长会压缩剩余空间。
• 单连接和多连接测试均无法满足实际传输需求。
• 资源利用率尚未饱和，但请求已经出现排队、超时或错误。
• 同一问题在多个采样日、相同时间段重复出现。

这样得到的美国服务器性能评估，既能回答当前延迟、IOPS 和带宽表现，也能说明这些结果适用于什么测试环境、哪些负载条件，以及何时需要复测或扩容。