实例标注的带宽不等于应用实际能持续使用的吞吐量。要完成计算实例网络吞吐量的压测与瓶颈分析，应先明确测量路径，再分方向、分负载测试，并对照实例规格与运行指标判断限制来自哪里。以下方法适用于你有权限管理的两台计算实例。
先确定测量口径
吞吐量通常以 bit/s 表示，文件传输工具显示的 MB/s 则按 byte 计；换算时，1 MB/s 约等于 8 Mbit/s。结果还会受实例规格、网络路径、虚拟网卡、协议开销和测试时的 CPU 负载影响，因此单次峰值不能直接代表长期可用速度。
先确认两台实例之间的网络连通性、路由和防火墙规则，并查明服务商对单实例带宽、突发能力及出入方向是否有不同限制。若测试公网链路，结果还包含运营商路径和对端网络的影响，不能单独归因于实例网卡。
用 iperf3 做基准压测
选择两台规格和位置明确的实例，一台作为接收端运行 iperf3 服务，默认监听端口为 5201；另一台作为发送端。按实际防火墙策略，只向测试端开放所需端口。
先测单连接：发送端运行“iperf3 -c 接收端地址 -t 30”。将接收端地址替换为实际可达的地址；30 秒只是常用起点，短测适合快速排查，较长测试更容易观察持续负载下的波动。
再测反向流量：增加参数“-R”，观察接收端向发送端传输时的结果。双向结果差异明显时，检查实例带宽规则、路由和两端负载。
逐步增加并行 TCP 流，例如使用“-P 4”，并与单流结果比较。并发流能帮助判断单连接是否受窗口、往返时延或单核处理能力限制，但并发数越大，越可能把 CPU 或整条链路压满。
每种设置至少重复数次，记录时间、方向、并发数和接收端报告值。需要测试 UDP 时，可使用“-u -b 目标速率”指定负载，并从较低速率逐档提高，同时观察丢包；不要直接把目标设到链路极限。
结果怎么读，瓶颈怎么找
| 现象 | 优先检查 |
|---|---|
| 单流偏低，并发后明显上升 | 单连接限制、往返时延、TCP 窗口或单核处理能力；比较不同并发数，而非只看最高值。 |
| 并发后仍停在相近水平 | 实例带宽上限、共享链路、网卡队列或对端能力；核对规格说明并查看平台提供的网络指标。 |
| UDP 速率提高后丢包增多 | 接收端处理能力、链路拥塞或队列丢弃。UDP 不会像 TCP 那样自动降低发送速率，需结合丢包率判断可用范围。 |
| 吞吐量忽高忽低 | CPU 抢占、其他业务流量、突发带宽耗尽或路径变化；避开业务高峰重测，并同时记录 CPU 与网卡收发、丢包、重传指标。 |
TCP 测试更接近可靠传输场景，适合观察应用常见的稳定传输能力；UDP 可用于验证特定速率下的丢包表现，但不能把发送端设定速率当成有效吞吐量。还要注意全双工条件：发送和接收方向可分别测试，不能把双向数值简单相加后称为单方向带宽。
如果测试的是跨区域或公网路径，先在相同网络位置的实例间做基线，再逐步扩大测试范围；本地基线正常而远端明显下降，问题更可能在路径或对端。由此形成的计算实例网络吞吐量的压测与瓶颈分析记录，应包含规格、测试方向、协议、并发数、持续时间及接收端结果，便于复测和比较。
常见问题
一次测试多久比较合适？
快速摸底可先测约 30 秒；排查持续负载波动时可延长到 1 分钟或更久，并重复测试。具体时长取决于是否存在突发带宽和业务波动。
为什么测出来达不到规格标称带宽？
标称值可能受实例档位、突发规则、方向和网络路径影响；CPU、并发连接及对端能力也会限制结果。先核对适用条件，再做同路径复测。
能否直接用下载速度判断吞吐量？
不宜。下载速度还受文件服务器、磁盘、协议和客户端影响。需要定位实例网络能力时，应优先使用两端可控的压测工具，并结合接收端统计分析。
结论应来自多次、双向、可复现的测试，而不是单个峰值。按上述步骤完成计算实例网络吞吐量的压测与瓶颈分析，才能把链路限制与实例、对端及测试方法本身区分开。