iphone怎么用iperf测吞吐量

很多用户在采购了艾尔麦Wi-Fi Analyzer后，不知道如何进行基于IPerf的吞吐量测试，现在把这个过程跟大家详细的介绍一下。Wi-Fi Analyzer工具中的“Throughtput/Iperf”功能，可以帮助用户进行端到端的性能检测，即STA-AP-STA模式。因此，如果要想进行此类测试，需要做如下 *** 作:1、 配置测卡:在微软系统下可以正常关联被测AP(即所谓的Zero-Config设置)2、 在Wi-Fi Analyzer配置中将测试网卡工作设置为“混合模式”3、 选择一台笔记本做无线吞吐量测试远端接收设备，并进行Iperf软件，运行“Iperf –s”4、 在工具选项中，选择“Throughput/Iperf”，选择关联AP并进行相关吞吐量的测试参数设定(包括，上下行、测试时间等)5、 然后选择 “Iperf Performance Test”选项6、 在Server中输入对端STA(站点)IP地址7、 Start开始测试此外，iperf的命令参数可以通过“iperf –help”查看，另外，还有一个软件也可支持，即jperf，该软件是WIN32系统，有图形 *** 作介面，效果更加。

系统吞吐量是指在单位时间内中央处理器（CPU）从存储设备读取、处理、存储信息的量。

影响因素：

存储设备的存取速度，即从存储器读出数据或数据写入存储器所需时间；CPU性能：时钟频率；每条指令所花的时钟周期数（即CPI）；指令条数；系统结构：如并行处理结构可增大吞吐量。

扩展资料：

网络吞吐量：

吞吐量的大小主要由网络设备的内外网口硬件，及程序算法的效率决定，尤其是程序算法，对于像防火墙系统这样需要进行大量运算的设备来说，算法的低效率会使通信量大打折扣。

因此，大多数防火墙虽号称100M防火墙，由于其算法依靠软件实现，通信量远远没有达到100M,实际只有10M-20M。纯硬件防火墙，由于采用硬件进行运算，因此吞吐量可以接近线速，达到90-95M，是真正的100M防火墙。

吞吐量和报文转发率是关系网络设备应用的主要指标，一般采用FDT(FullDuplexThroughput)来衡量，指64字节数据包的全双工吞吐量，该指标既包括吞吐量指标也涵盖了报文转发率指标。

吞吐量的测试方法是：在测试中以一定速率发送一定数量的帧，并计算待测设备传输的帧，如果发送的帧与接收的帧数量相等，那么就将发送速率提高并重新测试；如果接收帧少于发送帧则降低发送速率重新测试，直至得出最终结果。吞吐量测试结果以比特/秒或字节/秒表示。

参考资料来源：百度百科——吞吐量

吞吐量的度量单位是请求数/秒。

吞吐量是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。

吞吐量的大小主要由网络设备的内外网口硬件，及程序算法的效率决定，尤其是程序算法，对于像防火墙系统这样需要进行大量运算的设备来说，算法的低效率会使通信量大打折扣。

因此，大多数防火墙虽号称100M防火墙，由于其算法依靠软件实现，通信量远远没有达到100M,实际只有10M-20M。纯硬件防火墙，由于采用硬件进行运算，因此吞吐量可以接近线速，达到90-95M，是真正的100M防火墙。

吞吐量和报文转发率是关系网络设备应用的主要指标，一般采用FDT(Full Duplex Throughput)来衡量，指64字节数据包的全双工吞吐量，该指标既包括吞吐量指标也涵盖了报文转发率指标。

吞吐量的测试方法是：在测试中以一定速率发送一定数量的帧，并计算待测设备传输的帧，如果发送的帧与接收的帧数量相等，那么就将发送速率提高并重新测试；如果接收帧少于发送帧则降低发送速率重新测试，直至得出最终结果。吞吐量测试结果以比特/秒或字节/秒表示。

性能测试报告中吞吐量是一个非常重要的指标，该指标描述了被测系统在 一秒钟 内能够处理的 请求/交易数目 。吞吐量有时候也叫做每秒事务处理数（Transaction Per Second，简称TPS），TPS的粒度更大一些，落实到具体的测试脚本上，就是将一系列的请求组合成一笔交易，以这笔交易作为衡量吞吐量的最小粒度。但是吞吐量这个指标的数据有时候会“捣乱”，如果只是看其中的一些表面意义的话，解读出来的数据就会有很大的问题，甚至会误导对被测系统能力的判断。那XMeter君就来带领大家看一下吞吐量这个指标后面的秘密。

吞吐量的计算方式1：假设累积一段时间t秒的请求或者交易数目为c，计算吞吐量为：c/t = x（个/秒）。比如在一分钟内，被测系统能够处理30笔交易，那么该系统的吞吐量为30/60（秒）=05，我们称该系统的吞吐量为05。同理，如果在5秒钟内，被测系统能够处理6个请求，那么吞吐量为6/5=12。

吞吐量的计算方式2：如果针对单个用户单笔交易的处理时间为x秒，那么每秒能够处理的交易数为1/x。假设现有y个用户，假设系统能轻松处理这y个用户的请求，那么该系统的针对该交易的吞吐量为: y/x。根据此种计算方法，如果单笔交易时间是05秒，那么一秒钟能处理2笔交易，如果系统能够同时服务10个用户，那么该系统的吞吐量为20

这两种计算方式都没有问题，正常情况下应该可以互相印证。但是我们现在来研究一下下面的这个JMeter测试脚本，该脚本非常简单，它的任务是判断每个虚拟用户里循环执行的次数，只有在偶数次的时候才会执行Debug Sampler里的请求。

- 计数器：用于计数，得到当前运行的次数。具体设置如下图所示，启动值为1，递增为1，最后把值存入iterationNum变量中

- 如果（If）控制器：用于判断是否执行Debug Sampler，逻辑如下，如果变量iterationNum是偶数的话Debug Sampler才会被执行。

Debug Sampler是JMeter提供的内置Sampler，主要任务用于打印JMeter的虚拟用户中的变量等值，用于调试脚本之用。该Sampler主要是从内存中读取并打印变量的值，没有网络等费时的 *** 作，一般来说其执行速度会非常之快，由此可见如果执行上述测试脚本的时候，其吞吐量会非常的高。如下图所示，是该脚本在XMeter上运行的结果截屏。可以看到该Sampler的平均响应时间非常小，大概为001毫秒，按照我们脚本的逻辑，由于没有思考时间，而且该Sampler的执行速度非常快，所以基本上可以认为该脚本大概每隔百分之一毫秒就可以完成一次请求，那么在一秒钟内一个用户应该可以完成100000个请求，所以吞吐量应该大约为10万。可是读者看一下下面的测试报告会发现吞吐量才242！那么问题出在哪儿了？

我们来看一下，XMeter君得出10万的吞吐量是基于我们之前列出的第二种计算方式，这种计算方式有一个假设前提： 测试工具能够毫无延迟的情况下在完成了一次请求的时候，马上发出第二次请求 。回到我们的脚本，意味着第一次请求完成需要001毫秒，然后001毫秒之后JMete马上就可以发出第二次请求。我们可以看一下脚本里用了“如果（If）控制器”，该控制器里有一个表达式用于判断是否要执行Debug Sampler，问题主要就出在这个控制器上了：该控制器拖慢了JMeter执行脚本的速度，根据XMeter测试报告中实际的吞吐量的值，我们大概可以估算出该控制器的执行所需时间约为1000/242=4毫秒（Debug Sampler的时间量级与控制器的执行基本可以忽略不计了）。那有的同学可能就会说，这个JMeter也太差了吧，怎么会造成这么大的误差！不过你要是这么想可真冤枉了JMeter了，如果没有这些控制器的话，你怎么写出模拟各种业务场景的测试脚本呢？既想马儿不吃草，又想马儿跑得好，哪有这么两全其美的事情呢？

当然了，其实JMeter对于“如果（If）控制器”还是有优化的方法的，缺省的情况下该控制器用的是JavaScript的表达式运算方式，你想想每次执行的时候先JMeter需要把JavaScript引擎先起来，然后执行一下得到表达式的结果，这得花多少时间啊。在使用“如果（If）控制器”的时候可以用JMeter提供的jexl3函数来提高脚本执行效率，如下图所示，表达式变成了 ${__jexl3(${iterationNum} % 2 == 0)} 之后，同样的测试脚本吞吐量变成了1813，但是离100000的理论值还是差的很远，但是毕竟比刚才的测试结果已经提升了7倍多。

话说到这儿，读者是不是对JMeter生成的测试结果感到很不可靠？差不多的脚本，这个吞吐量的值也差的太远了。工具在实现的时候对功能的复杂性、易用性和准确性等方面都会综合考虑，我们这里举的例子比较极端，如果真正理解了背后的原理，是可以解决的。造成这个问题的根源在于：Sampler的响应时间太短，而脚本中别的元素执行时间远远超过了正常Sampler的执行时间，从而导致这么大的误差，了解了该问题，我们就可以在编写测试脚本的时候避免类似的问题。因此用户在写脚本的时候如果发现了被测服务的响应时间比较短，那么最好通过在Sampler之间增加比响应时间大几个数量级的思考时间，然后通过增加虚拟用户数目的方式来测试被测系统的吞吐量，尽量减少测试工具本身可能会对测试结果产生的不利影响。否则可能会得出“无法解释”的吞吐量报告。

---