iperf3怎样测试多线程

本文目录导读：

1. 基本多流（多线程）测试
2. 结合其他参数进行精细测试
3. 关键观察与注意事项
4. 解读输出结果
5. 总结：什么时候用多少线程？

iperf3 本身是单线程设计的（在大多数默认情况下），但可以通过其 -P 参数（代表 Parallel）来创建多个并行的客户端流（streams），从而模拟多线程或并发连接的行为。

注意：iperf3 默认使用单线程来处理这些并行流（即在单个 CPU 核心上轮询多个 socket），直到较新的版本（3.16+ 左右）开始支持 --sctp 或通过特定编译选项启用真正的多线程，不过对于常规 TCP 测试，使用 -P 参数就是“多线程/多连接”的测试方式。

以下是详细的测试命令和解释：

基本多流（多线程）测试

服务端（Server）： 通常不需要特殊参数，只需启动监听。

iperf3 -s

客户端（Client）： 使用 -P 参数指定并行流的数量（10 个流）：

iperf3 -c <服务器IP> -P 10

• -c：客户端模式。
• -P 10：同时建立 10 个 TCP 连接并并行发送数据。

结合其他参数进行精细测试

通常多线程测试会结合以下参数,以压满带宽或模拟真实场景：

# 测试 30 秒，使用 8 个并行流
iperf3 -c 192.168.1.100 -t 30 -P 8

# 双向测试（客户端和服务器同时发送），并使用 4 个并行流
iperf3 -c 192.168.1.100 -d -P 4

# UDP 测试（UDP 本身无连接，但-P可创建多个流，模拟多路并发）
iperf3 -c 192.168.1.100 -u -b 1000M -P 4

注意：UDP 的 -b 用来指定总目标带宽，多流时每个流平分目标带宽。

关键观察与注意事项

• 单CPU瓶颈：
  • 默认的 iperf3 在单 CPU 核心上运行，即使使用 -P 100，也可能因为单个核心无法处理大量 socket 的中断和上下文切换，导致总吞吐量反而下降（尤其是小包高并发场景）。
  • 标志：如果服务器 CPU 使用率没跑满但带宽上不去，通常就是单核瓶颈。
• 如何解决单核瓶颈（进阶）：
  • 使用 iperf2：iperf2 支持真正的多线程（-P 参数会在多核上分配负载），适合老系统。
  • 使用 --affinity（iperf3 3.7+）： 可以手动将不同流绑定到不同 CPU 核心。

    # 服务端绑定到核心 0
    iperf3 -s --affinity 0
    # 客户端绑定到核心 1
    iperf3 -c 192.168.1.100 --affinity 1 -P 4

  • 运行多个单流 iperf3 进程（最可靠的多核利用方式）： 在脚本里并行启动多个 iperf3 客户端，每个一个 -P 1。

    # 在后台启动 4 个单流客户端
    iperf3 -c 192.168.1.100 -P 1 &
    iperf3 -c 192.168.1.100 -P 1 &
    iperf3 -c 192.168.1.100 -P 1 &
    iperf3 -c 192.168.1.100 -P 1 &
    wait

解读输出结果

客户端输出示例（简化）：

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   945 Mbits/sec    0    sender
[  7]   0.00-10.00  sec  1.08 GBytes   928 Mbits/sec    2    sender
[  9]   0.00-10.00  sec  1.09 GBytes   937 Mbits/sec    0    sender
[ 11]   0.00-10.00  sec  1.08 GBytes   928 Mbits/sec    1    sender
[SUM]   0.00-10.00  sec  4.35 GBytes  3.74 Gbits/sec    3    sender

• 每个 [ID] 代表一个并行流（如 [5], [7] 对应不同的 socket）。
• 最后一行 [SUM] 是所有流的总和，这是你真正关心的总带宽。

什么时候用多少线程？

核心建议： 对于大多数现代服务器和 10Gbps 网络，从 -P 4 开始测试并逐步增加到 -P 16，观察 [SUM] 行的带宽变化，是找到最佳并发数的常用方法。

标签： iperf3多线程测试