JMeter

1、计算线程组--循环次数

1、计算方法

线程数：n

Ramp-Up Period：T （有人称之为启动时间，有人说是准备时长，看个人喜好）

循环次数：a  

若每个循环运行时间是 t

当时间到 S = (T- T/n)时，最后一个线程启动，若要使所有线程同时运作，则需要在最后一个线程启动的时候第一个线程仍未关闭，为达到这个要求，需满足 a·t > S及a > S/t。

每一个个线程运行时间既是R = a·t(此处的a是大于S/t的某一值)，则第一个线程在时间点为R 的时候停止，整个测试理论运行时间则是 ：S + R = (1-1/n)·T + a·t

 

1丶实例
初始设置：设置线程数 n = 80，循环次数a = 1，ramp-up period=5

一 计算最后一个线程的生成时间（last）

　　总共生成80个线程，总共需要5秒，每秒钟会启动16个线程，所以，最后一个线程开始启动的时间应该为第1个线程启动之后的第4.9秒，即：ramp-up period*(1-1/n)=5*(1-1/80)=4.9秒

二 获取平均相应时间（avg）

　　平均相应时间：聚合报告-average值，例如为206，则为时间为：206/1000=0.206秒

三 计算循环次数（x）

x〉last/avg=4.9/0.206=23.7，即：循环次数至少大于24

 

第一个线程的第二次循环时间起点：第一个线程结束后，立刻继续第二次循环
业内对于在线实时交易响应时间标准：
互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。

金融企业：1秒以下为佳，部分复杂业务3秒以下。

保险企业：3秒以下为佳。

制造业：5秒以下为佳。

对于批量交易：

不同数据量结果是不一样的，大数据量的情况下，2小时内完成。

 

2、响应时间

响应时间（=采样时间=负荷时间=经过时间）是当响应已经完全接收时，请求被发送的时间和时间之间的区别。

所以，响应时间总是> =延迟。

较大的文件，响应时间和等待时间相差较大会。

 

 

 

3、监听器：图形结果、聚合报告、用表格察看结果指标报告分析

一、图形结果

横坐标：时间。（单位：毫秒） 

纵坐标：处理时间。（单位：毫秒）

样本数目：样本数目 = 线程数（请求用户数）* 请求次数 。（单位：个）

最新样本：最后一个请求的处理时间。（单位：毫秒）

偏离：表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。（单位：个）

吞吐量：服务器每分钟处理的请求量 。（单位：请求数/分钟）

平均：每个请求的平均处理时间 。（单位：毫秒）

中值：所有处理时间的中位数，有一半的服务器响应时间低于该值而另一半高于该值。（单位：毫秒）

 

二、聚合报告

 

Label：每个请求的自定义名称（无修改时默认显示请求类型，如Http，FTP等请求）；“TOTAL”是所有请求的总统计。

#Samples：采集器的数量，总共发送到服务器的样本数目。样本数目 = 线程数 * 循环次数。（单位：个）  

Average：单个请求的平均响应时间，默认是单个Request的平均响应时间。（单位：毫秒）

当使用了Transaction Controller时，也可以以Transaction为单位显示平均响应时间。           

Median：响应时间中位数，N个数据从小到大排列，第N/2个数的数值。（单位：毫秒） 

9x%Line：所有响应时间数据中，9x%的响应时间都小于此值。（单位：毫秒）

所有响应时间，N个数据按从小到大排列，取第（9x% * N）个数的响应时间数值。          

①9X%Line的含义：

数据按由小到大的顺序排列后，取出第9X%位。

比如：2、5、1、5、3、8、0、2、1、9中，90%line就是8：

1. 数据按照升序进行排列 0、1、1、2、2、3、5、5、8、9

2. 10个数字，第90%位就是10*90%，第9位

3. 第9位是8，所以90%line就是8

②9X%Line的意义：

⒈当一组数升序排列好后，选出第9X%位，那就意味着前9X%个数字都小于等于它，也就代表着改组数据中有9X%的数小于等于该数字。

因此：

90%line就代表该组数据中有90%的数字小于等于该值。

95%line就代表该组数据中有95%的数字小于等于该值。

99%line就代表该组数据中有99%的数字小于等于该值。

⒉用在性能测试上，将显得十分的有意义。

比如：在响应时间中，代表着一组请求中，9X%请求响应不会超过该值。可以有效的进行性能评估。

Min：最短的响应时间。（单位：毫秒）

Max：最长的响应时间。（单位：毫秒）

Error%：出错的百分率，错误率 = 本次测试中出现错误的请求的数量 / 请求的总数 * 100% 。

Throughput：吞吐率，表示每秒完成的请求数，吞吐率 = 请求数 / 总时间（秒）。（单位：个/秒）

当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数。                              

Received KB/sec：服务器端接收速率，每秒从服务器端接收到的数据量，即：收到的千字节每秒的吞吐量测试。（单位：千字节/秒）

Sent KB/sec：客户端接收速率，每秒从客户端发送的请求的数量，即：发送的千字节每秒的吞吐量测试。（单位：千字节/秒） 

 ①吞吐率：

⒈吞吐率（Throughput）：单位时间内服务器处理的请求数来描述其并发处理能力，单位是 “req/s”。

⒉吞吐率，特指Web服务器单位时间内处理的请求数。

⒊吞吐率，是单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。

⒋吞吐率是衡量网络性能的重要指标。通常情况下，吞吐率用“字节数/秒”来衡量。也可以用“请求数/秒”和“页面数/秒”来衡量。

备注：一个请求还是一个页面，它的本质都是在网络上传输的数据，那么用来表述数据的单位就是字节数。

⒌吞吐量除以时间，所得到的单位时间内的数据量就是吞吐率。

⒍吞吐率代表着单位时间内所能承受的压力，是测试中一个重要的指标。

通过比较吞吐量，可以发现系统的运行状态。

⒎当随着并发数增加时，吞吐率是不断增加的，当达到一个服务器极限后，再增加并发数，吞吐率会急速下降，直至服务器崩溃。

所以，当达到临界点（吞吐量最高点，负载和处理均衡时）为“最大吞吐率”，是系统在运行下的一个理想阈值范围。

  ②吞吐量：

⒈吞吐量：是指在一次性能测试过程中，网络上传输的数据量的总和。

⒉对于交互式应用来说：吞吐量指标反映的是服务器承受的压力。

在容量规划的测试中：吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力。

另外，在性能调优过程中，吞吐量指标也有重要的价值。

比如：一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，说明的是这个运输能力（吞吐量）是整个系统的瓶颈。

⒊只用吞吐量来衡量一个系统的性能（输出能力）是极其不准确的。

用个最简单的例子说明，一个水龙头开一天一夜，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。

此时当然是一个水龙头的吞吐量大。但是，你能说1个水龙头的出水能力是10个水龙头的强吗？显然不能。

所以，我们要加单位时间，看谁1秒钟的出水量大，这就是吞吐率。

 ③TPS：

⒈TPS:事务(Transaction Per second),就是用户某一步或几步操作的集合。同时，要保证它有一个完整意义。

比如：用户对某一个页面的一次请求，用户对某系统的一次登录，淘宝用户对商品的一次确认支付过程。

这些我们都可以看作一个事务。

⒉TPS:每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

⒊点击率：可以看做是TPS的一种特定情况。

点击率：更能体现用户端对服务器的压力。

TPS：更能体现服务器对客户请求的处理能力。

⒋TPS:每秒钟用户向web服务器提交的HTTP请求数。

这个指标是web 应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。

如果把每次点击定义为一个交易，点击率和TPS就是一个概念。

点击率越大，对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

注意：这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。

④吞吐量、吞吐率的意义：

⒈吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对地对吞吐量设计测试，可以协助尽快定位到性能冰晶所在的位置。

⒉80%系统的性能瓶颈都是由吞吐量制约。

⒊并发用户和吞吐量瓶颈之间存在一定的关联。

⒋通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身4个环节确定系统的性能瓶颈。

⑤聚合报告中部分值的计算方法：

1. 吞吐量 = 完成的请求数 / 完成这些请求数所需要的时间

2. 平均响应时间 = 所有响应时间的总和 / 完成的请求数

3. 失败率 = 失败的个数 / 总数

4. 时间的计算方法是：通过timeStamp时间戳（发出的起始时间）相减而得

 

三、用表格察看结果

 

Sample#：每个请求的序号。

Start Time：每个请求开始时间。（时：分：秒.毫秒）

Thread Name：每个线程的名称（线程序号-第N次循环次数）。

Label：每个请求的自定义名称（无修改时默认显示请求类型，如Http，FTP等请求）。

Sample Time(ms)：每个请求的响应时间。（单位：毫秒）

Status：请求状态，如果为勾则表示成功，如果为叉表示失败。

Bytes：响应的字节数，请求的字节数。

Sent Bytes：发送的字节数。 

Latency：延迟的时间，等待时长。（单位：毫秒）

Connect Time(ms)：连接服务器的时间。（单位：毫秒）

样本数目：所有请求个数，样本数目 = 线程数（请求用户数）* 请求次数 。（单位：个）

平均：所有请求的平均响应时间。（单位：毫秒）

最新样本：最新样本响应时间，表示服务器响应最后一个请求的时间。（单位：毫秒）

偏离：服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。

①Bytes：

Byte，字节

字节是由8个位所组成，可代表一个字符(A~Z)、数字(0~9)、或符号(,.?!%&+-*/)，是内存储存数据的基本单位。

1 byte = 8 bit

1 KB = 1024 bytes =210 bytes

1 MB = 1024 KB = 220 bytes

1 GB = 1024 MB = 230 bytes

 

 

4、jmeter非gui执行
 

jmeter -n -t D:\jmeter_project\my_project\保单核查.jmx -r -l D:\jmeter_project\my_project\result.jtl -e -o D:\jmeter_project\my_project\test

 

保单核查.jmx---文件

\result.jtl------jmeter自己生成的报告文件

D:\jmeter_project\my_project\test---必须为空文件，用于存放html报告

 

n表示无GUI运行

t表示要运行的jmx文件

l指生成的文件名称

r指远程将所有agent启动

 

 

5、分布式测试
当客户端线程数需要较大数量时（对jmeter而言，超过1000左右），客户机/测试机的资源占用会增大，整个客户端的请求构造时间会拉长。应该考虑分布式测试。

 

1、从机

remote_hosts=127.0.0.1

#remote_hosts=localhost:1099,192.168.1.58:1011

#remote_hosts=localhost:1099,localhost:2010

 

server_port=1011

切记要修改：server.rmi.ssl.disable=true

打开jmeter-server.bat

 

2、主机

#remote_hosts=127.0.0.1

remote_hosts=localhost:1099,192.168.1.58:1011

#remote_hosts=localhost:1099,localhost:2010

server_port=1099

切记要修改：server.rmi.ssl.disable=true

打开jmeter-server.bat

 

GUI模式再打开jmeter.bat--运行--远程启动所有

非GUI模式，jmeter -n -t D:\tools\jmeter5.3\apache-jmeter-5.3\bin\线程组.jmx -r -l D:\jmeter_project\my_project\result.jtl -e -o D:\jmeter_project\my_project\test

 

6、Jmeter压测接口的性能优化

Jmeter压测减少资源使用的一些建议，即压测结果更准确
1、使用非GUI模式：jmeter -n -t test.jmx -l result.jtl
2、少使用Listener， 如果使用-l参数，它们都可以被删除或禁用。
3、在加载测试期间不要使用“查看结果树”或“查看结果”表监听器，只能在脚本阶段使用它们来调试脚本。
4、包含控制器在这里没有帮助，因为它将文件中的所有测试元素添加到测试计划中。]
5、不要使用功能模式,使用CSV输出而不是XML
6、只保存你需要的数据,尽可能少地使用断言
7、如果测试需要大量数据，可以提前准备好测试数据放到数据文件中，以CSV Read方式读取。
8、用内网压测，减少其他带宽影响压测结果
9、如果压测大流量，尽量用多几个节点以非GUI模式向服务器施压