压力测试工具-jmeter

[[Oracle APEX]]

说明

Jmeter中文网
 Jmeter 压测工具使用手册（完整版） - 赵羴 - 博客园 (cnblogs.com)
Jmeter的基本使用（Jmeter压测实战） - 知乎 (zhihu.com) Jmeter之CSS选择器/JQuery选择器关联 - Orange_ysen - 博客园 (cnblogs.com)

alt text

安装

参考

使用

启动GUI (base) ➜ ~ jmeter
创建线程计划和线程组与设置线程数
线程组：测试里每个任务都要线程去处理，所有我们后来的任务必须在线程组下面创建。然后在线程组面板里有几个输入栏： Number of Threads(users)、Ramp-Up Period (in seconds)、循环次数 Number of Threads (users): 一个用户占一个线程， 100 个线程就是模拟 100 个用户
Ramp-Up Period (in seconds): 表示在这时间内创建完所有的线程。
如: 有 8 个线程，Ramp-Up = 200 秒，那么线程的启动时间间隔为 200/8=25 秒，这样的好处是：一开始不会对服务器有太大的负载。
设置线程需要多长时间全部启动。如果线程数为 200 ，准备时长为 10 ，那么需要 1 秒钟启动 20 个线程。也就是每秒钟启动 20 个线程。
Loop Count: 每个线程发送请求的次数。如果线程数为 200 ，循环次数为 10 ，那么每个线程发送 10 次请求。总请求数为 200*10=2000 。如果勾选了 “永远”，那么所有线程会一直发送请求，直到选择停止运行脚本。
添加请求，设置请求
登录请求

OsXM1-2024-09-26-13-03-06

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{"pageItems":{
	"itemsToSubmit":[
		{"n":"P9999_USERNAME","v":"demo"},
		{"n":"P9999_PASSWORD","v":"demodemo"},
		{"n":"P9999_REMEMBER","v":"N"}
		],
	"protected":"/yrpNU9NqAfevC_P6mSCuO85unA1wKhQFgU7mxL-5HRMI5lC4ro7Gk1by3cEu-JdWbsWSfj-xBcl8z7ylIBDXRw",	
	"rowVersion":"","formRegionChecksums":[]
	},
"salt":"245457740559706892853384382393063096975"
}

四、jmeter 指标说明 (注：其中)

1、表格显示，属性说明

alt text

Sample：每个请求的序号
Start Time：每个请求开始时间
Thread Name：每个线程的名称
Label：Http 请求名称
Sample Time：每个请求所花时间，单位毫秒
Status：请求状态，如果为勾则表示成功，如果为叉表示失败。
Bytes：请求的字节数
样本数目：也就是上面所说的请求个数，成功的情况下等于你设定的并发数目乘以循环次数
平均：每个线程请求的平均时间
最新样本：表示服务器响应最后一个请求的时间
偏离：服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布
2、聚合报告显示属性说明

alt text

Label：每个 JMeter 的 element 的 Name 值。例如 HTTP Request 的 Name

#Samples：样本数量。多少个请求

Average：平均响应时间（单位：）。默认是单个 Request 的平均响应时间，当使用了 TransactionController 时，也可以以 Transaction 为单位显示平均响应时间

Median：中位数，也就是 50% 用户的响应时间

90% Line：90% 用户的响应时间

95% Line：95% 用户的响应时间

99% Line：99% 用户的响应时间

注：为什么要有 *% 用户响应时间？因为在评估一次测试的结果时，仅仅有平均事物响应时间是不够的。假如有一次测试，总共有 100 个请求被响应，其中最小响应时间为 0.02 秒，最大响应时间为 110 秒，平均事务响应时间为 4.7 秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？

我们可以在 95 th 之后继续添加 96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用 Excel 的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且 99％的用户请求的响应时间都是在性能需求所定义的范围之内的；如下图则是最低响应时间的值出现几率是很小的，实际 99% 的用户请求响应时间都要 20000+。

Min：最小响应时间

Max：最大响应时间

Error%：本次测试中出现错误的请求的数量 / 请求的总数

Throughput：吞吐量。默认情况下标示每秒完成的请求数（具体单位如下图）

KB/sec：每秒从服务器端接收到的数据量。

3.Summary Report 界面，属性说明

alt text

所有数据写入一个文件：保存测试结果到本地。

文件名：指定保存结果。

仅日志错误：仅保存日志中报错的部分。

Successes：保存日志中成功的部分。

Configure：设置结果属性，即保存哪些结果字段到文件。一般保存必要的字段信息即可，保存的越多，对负载机的 IO 会产生影响。

Label：取样器名称（或者是事务名）。

#Samples：取样器运行次数（提交了多少笔业务）。

Average：请求（事务）的平均响应时间，单位为毫秒。

Min：请求的最小响应时间，单位为毫秒。

Max：请求的最大响应时间，单位为毫秒。

Std.Dev：响应时间的标准方差。

Error%：事务错误率。

Throughput：吞吐率（TPS）。

KB/sec：每秒数据包流量，单位是 KB。

Avg.Bytes：平均数据流量，单位是 Byte。

六、附加信息

1、jmeter 在 linux 下进行压力测试
1.1、jmeter 在 linux 安装
简单说下，就是要先安装 jdk, 同时再配置环境变量，最后再上传 jmeter 压缩的安装包，在 linux 下解压完安装包就可以使用了。jmeter 在 linux 运行
进入 jmeter 下的 bin 目录下运行脚本，未配置 jmeter 环境变量的条件下，运行的命令：

./jmeter -n -t a.jmx -l res.jtl

其中 a.jmx 是准备好的 jmeter 脚本，res.jtl 是测试结果文件，测试结果文件可以导入到 jmeter 察看结果树下查看。

七、压力测试

1、压力测试场景
压力测试分两种场景：

一种是单场景，压一个接口的；

第二种是混合场景，多个有关联的接口。压测时间，一般场景都运行 10-15 分钟。如果是疲劳测试，可以压一个小时、一天或一周，根据实际情况来定。

2、压测任务需求的确认

压测前要明确压测功能和压测指标，一般需要确定的几个问题：

固定接口参数进行压测还是进行接口参数随机化压测？
要求支持多少并发数？
TPS（每秒钟处理事务数）目标多少？响应时间要达到多少？
2.4、压服务器名称还是压服务器 IP，一般都是压测指定的服务器

3、压测设置
线程数：并发数量，能跑多少量。具体说是一次存在多少用户同时访问
Rame-Up Period (in seconds): 表示 JMeter 每隔多少秒发动并发。理解成准备时长：设置虚拟用户数需要多长时间全部启动。如果线程数是 20，准备时长为 10，那么需要 10 秒钟启动 20 个数量，也就是每秒钟启动 2 个线程。
循环次数：这个设置不会改变并发数，可以延长并发时间。总请求数 = 线程数 * 循环次数
调度器：设置压测的启动时间、结束时间、持续时间和启动延迟时间。
4、压测结果查看

运行完后，聚合报告会显示压测的结果。主要观察 Samples、Average、error、Throughput。

Samples: 表示一共发出的请求数
Average：平均响应时间，默认情况下是单个 Request 的平均响应时间（ms）
Error%: 测试出现的错误请求数量百分比。若出现错误就要看服务端的日志，配合开发查找定位原因
4.4、Throughput: 简称 tps, 吞吐量，默认情况下表示每秒处理的请求数，也就是指服务器处理能力，tps 越高说明服务器处理能力越好。

5、压测结果的分析

有错误率同开发确认，确定是否允许错误的发生或者错误率允许在多大的范围内；

5.1、Throughput 吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；

若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；压测结束，登陆相应的 web 服务器查看 CPU 等性能指标，进行数据的分析；

5.2、最大的 tps: 不断的增加并发数，加到 tps 达到一定值开始出现下降，那么那个值就是最大的 tps。

5.3、最大的并发数：最大的并发数和最大的 tps 是不同的概率，一般不断增加并发数，达到一个值后，服务器出现请求超时，则可认为该值为最大的并发数。

5.4、压测过程出现性能瓶颈，若压力机任务管理器查看到的 cpu、网络和 cpu 都正常，未达到 90% 以上，则可以说明服务器有问题，压力机没有问题。

5.5、影响性能考虑点包括：数据库、应用程序、中间件（tomact、Nginx）、网络和操作系统等方面。