当前版本:
- jmeter 5.6.3
- mysql 5.7.39
简介
JMeter 通过 BZM - Arrivals Thread Group 来模拟并发到达的用户流量、按时间加压,可以有效地帮助测试人员评估系统在高压力和高并发情况下的性能表现。
文章目录如下
1. 下载插件
2. 界面说明
3. 测试步骤
3.1. 添加压测线程组
3.2. 设置JDBC配置
3.3. 构造简单业务
3.4. 配置监听器
3.5. 运行测试
4. 按秒压测
1. 下载插件
地址如下(下载2个包,一个用于阶梯式压测,一个用于增加性能监听器)
Download :: JMeter-Plugins.org
(注意:JMeter版本5.2.0以上)
将下载的两个zip包解压后,找到 JMeterPlugins-Standard.jar 和 JMeterPlugins-Extras.jar,放到 jmeter\lib\ext\ 下,重启 jmeter 生效。
2. 界面说明
添加阶梯式压测线程组
- 右击测试计划 → 添加 → 线程(用户) → bzm - Arrivals Thread Group
界面说明
- Target Rate:目标速率 (请求数,可以理解为最大吞吐量)。如果选择下面单位为分钟,那么这里的 10000 就是每分钟吞吐量达到10000;如果选择秒,则表示每秒达到10000。
- Ramp Up Time:设置多久达到最大请求数
- Ramp Up Steps Count:设置阶梯次数(默认0,直线上升)
- Hold Target Rate Time:达到最大请求数后,设置继续运行时间
- Time Unit:选择时间单位(minutes:分,second:秒)
- Thread lterations Limit:线程迭代限制(每个线程执行测试计划的次数)
- Log Thread Status into File:将线程状态记录到文件
- Concurrency Limit:并发限制
3. 测试步骤
jmeter 通过如下组件来构造高并发:
bzm - Arrivals Thread Group # 模拟吞吐量阶梯式压测
JDBC Connection Configuration # 配置数据库连接信息
JDBC Request # 构造业务
通过如下监听器来查看性能指标
聚合报告 # 查看整体性能指标
jp@gc - Response Times Over Time # 查看响应时间走势图表
jp@gc - Transactions per Second # 查看吞吐量走势图表
jp@gc - Active Threads Over Time # 查看线程数走势
3.1. 添加压测线程组
- 右击测试计划 → 添加 → 线程(用户) → bzm - Arrivals Thread Group
需求:吞吐量在3分钟逐渐递增(共递增5次),最终吞吐量达到10000/分,达到1w后继续运行1分钟。配置如下:
3.2. 设置JDBC配置
- 右击测试计划 → 添加 → 配置元件 → JDBC Connection Configuration
"""MySQL"""
URL:jdbc:mysql://[IP]:[端口]/[数库名] # jdbc:mysql://localhost:3306/mysql
Driver:com.mysql.jdbc.Driver
"""Oracle"""
URL:jdbc:oracle:thin:@[IP]:[端口]:[数库名] #jdbc:oracle:thin:@localhost:1521:orcl
Driver:oracle.jdbc.OracleDriver
"""PostgreSQL"""
URL:jdbc:postgresql://[IP]:[端口]/[数库名] # jdbc:postgresql://localhost:5432/postgres
Driver:org.postgresql.Driver
3.3. 构造简单业务
- 右击线程组 → 添加 → 取样器 → JDBC Request
简单读语句(仅举例)
3.4. 配置监听器
- 右击线程组 → 添加 → 监听器 → 聚合报告
- 右击线程组 → 添加 → 监听器 → jp@gc - Response Times Over Time
- 右击线程组 → 添加 → 监听器 → jp@gc - Transactions per Second
- 右击线程组 → 添加 → 监听器 → jp@gc - Active Threads Over Time
所有基础配置如下:
3.5. 运行测试
【最终结果】聚合报告
【最终结果】响应时间
【最终结果】吞吐量
【最终结果】线程数
总结
我们配置的吞吐量为 10000/分,换算为每秒 10000 / 60 = 167。从上面测试结果来看,响应时间非常低,吞吐量很稳定,并且仅1个线程就能够满足要求,说明此次压测并没有达到数据库可承受的最大值,如果需要测试程序最大承受压力直接修改 Target Rate 即可。
4. 按秒压测
我们将单位设置为秒,那么设置的最大吞吐量就是每秒最大达到1000。这里分了5个阶梯,达到最大后持续运行 2+5分钟,观察是否指标稳定。
- Concurrency Limit 限制了最大100个线程数。
【结果如下】
吞吐量按需求持续增长,最终达到1000/s,相对稳定
线程数随着吞吐量的增加也是有所增长,整体也比较稳定
响应时间较快,也相对稳定。