注意iPerf3有-p和-P二个不同的参数,在iPerf里是区分大小写的,这个-p(见详解:iPerf3 -p参数详细图文分析)和-P的意义是不一样的。本文讲的是-P(大写字母)这个参数的使用。

这个参数,只能在客户端使用,原文对这个参数的说明如下:The number of simultaneous connections to make to the server. Default is 1.简单的翻译为:这个参数定义到本客户端到iperf3服务器端同时存在的连接数量,默认值是1。

在日常的测试工作中,我们发现当默认使用一个连接,数据流量,吞吐量(throughput)打不上去的时候,通常会想到加上-P参数用多个连接来加速。此时我们会简单的认为加了-P后,iPerf启动了多线程,所以增加了吞吐量,但实际情况并非如此,因为iperf3是不支持多线程的。-P增加了吞吐量其实是由于以下的原因。

  1. 测试UDP:

如果你发现-P能为你的测试增加吞吐量,通常是因为相比较于你的网络延时,一般时由于你的 UDP的接收缓冲区设置得太小了,导致网络带宽并没有充分利用,这里需要通过 -W参数增加接收缓冲区的大小。

  1. 测试TCP:

如果你发现-P能为你的测试增加吞吐量,通常是因为你处在长肥网络下,简单的说相比较于你的网络延时,你的TCP接收窗口设置得太小了,导致网络带宽并没有充分利用,这里可以通过 -W参数修改接收窗口的大小,当然也可以通过-P参数同时启动多条TCP来把网络带宽占满,或者启动多个iperf3进程来进行并行测试(-P和多iperf3进程测试本质上是把接收窗口变大成了n倍)。

具体可以参见以下文章来理解为什么TCP打流打不满的问题:

TCP滑动窗口协议与流量控制

TCP的三个窗口:发送窗口、接收窗口、拥塞窗口

长肥网络与TCP的长肥管道

所以,在其它参数都设置合适(比如有合适的发送窗口,不会因为发送端窗口过小而引发吞吐量偏小)的情况下,仅仅用-P参数把连接数量增加,并不能显著增加吞吐量。

我们要知道:

-P参数的场景是设计来模拟“客户端和服务端之间多连接”的测试场景而设计的。

-P参数的场景也可以简单的用来解决长肥网络中默认窗口不够大,导致TCP打不满的问题。

如果认为CPU的处理能力不足限制了收发包的速度进而影响了吞吐量的话,我们需要启动多个iperf3进程来进行测试(详见同时启动多个iperf3进程进行大流量测试)。

下面我们来详细看一下。

我们打开多个终端,

1,在第一个终端里运行服务端:

iperf3 -s -p 6666




airtest 启动多线程执行_airtest 启动多线程执行


2,在第二个终端里运行

iperf3 -c 192.168.3.107 -p 6666 -P 4 -t400

以4个并行连接的方式进行吞吐量测试


airtest 启动多线程执行_Powered by 金山文档_02


3,在第三个终端里

先用 ps -aux | grep iperf命令,查出iperf -s和iperf -c二个进程的PID分别是4460和8420

然后用sudo cat /proc/4460/status | grep Threads和sudo cat /proc/8420/status | grep Threads二个命令,可以发现iperf的服务和客户端二个进程在4个并行连接的情况下都是单线程工作的。

最后用ps -T -p 4460和ps -T -p8420确认iperf的服务和客户端二个进程的确只有一个线程(参考Linux下查看进程里的线程的方法)。


airtest 启动多线程执行_tcp/ip_03


通过以上测试我们可以发现在多个并行连接开启时,iperf并没有如我们第一反应那相是启动多线程来进行工作,以求增加吞吐量。

最大吞吐量其实取决于很多因素:

概括起来有3个节点的3个能力

3个节点:发送方主机,接收方主机,网络

3个能力:包处理能力,延时,带宽

所以发送方和接收方主机CPU处理能力,内存读定速度,发送方和接收方主机的网卡的最大包处理能力和最大带宽,发送方和接收方主机TCP/IP协议栈的包处理能力和最大带宽,发送方和接收方主机的接收发送延时,发送方和接收方主机socket缓冲区大小。

网络的带宽,延时,包处理能力

都会影响最大吞吐量的测试。

iperf没有启动多线程来处理收发包,说明iperf认为在普通测试场景下,当前主流的主机的CPU的包处理能力都是足够的。我们后续可以专门开一篇讲讲3个节点的3个能力是如何影响最大吞吐量的测试的。