jmeter 压测数据库

当前版本：

jmeter 5.6.3
mysql 5.7.39

简介

JMeter 是一个开源的 Java 应用程序，主要用于进行性能测试和负载测试。它支持多种协议，包括但不限于 HTTP、HTTPS、FTP、JDBC 以及各种 Web Services。对于数据库的压力测试可以使用 JDBC 协议与数据库进行通信。

文章目录如下

[1. 怎么实现高并发](#1. 怎么实现高并发)

[2. 配置压测的基本流程](#2. 配置压测的基本流程)

[2.1. 设置线程组](#2.1. 设置线程组)

[2.2. 配置数据库连接串](#2.2. 配置数据库连接串)

[2.3. 构造简单业务](#2.3. 构造简单业务)

[2.4. 配置监听器](#2.4. 配置监听器)

[2.5. 执行测试](#2.5. 执行测试)

[3. 业务并发分配](#3. 业务并发分配)

1. 怎么实现高并发

jmeter 通过如下组件来构造高并发：

bash 复制代码

线程组    # 模拟多个并发用户
JDBC Connection Configuration  # 配置数据库连接信息
JDBC Request  # 构造业务

通过如下监听器来查看性能指标

bash 复制代码

聚合报告    # 查看整体性能指标
jp@gc - Response Times Over Time  # 查看响应时间走势图表
jp@gc - Transactions per Second   # 查看吞吐量走势图表

在压测过程中，一般采用逐步增长并发数的方案来确定程序的承受能力：

首先确定吞吐量不低于多少，或者响应时间不高于多少。

确定需求后开始测试，第1次压测线程数设置与cpu数量相同。例如128，压测过程中检查吞吐量走势是否存在波动或下降的趋势。如果存在下降的趋势检查硬件是否出现瓶颈，检查数据库慢SQL原因。

如果第1次压测没有性能下跌，那么加大并发数。并发数以成倍数增长，比如第1次并发128，那么第2次256、第3次512，直到出现性能下跌或超出要求的吞吐量。

如果硬件和业务已经没有优化点了，那么我们只需要加压即可。例如要求达到10w吞吐量，检测程序的最大压力。如果配置的128并发吞吐量达到20w，那么可以持续加压，直到吞吐量只有10w。假如压测2000个并发持续1小时吞吐量都能平稳在10w，则表示符合要求，那么程序10w吞吐量的最大压力可达到2000个用户并发。

数据库的详细配置见另一篇文章：

https://blog.csdn.net/m0_61066945/article/details/135829691

性能监听器下载地址：

https://jmeter-plugins.org/downloads/old/

将下载的两个zip包解压后，找到 JMeterPlugins-Standard.jar 和 JMeterPlugins-Extras.jar，放到 jmeter\lib\ext\ 下，重启 jmeter 生效。

2. 配置压测的基本流程

2.1. 设置线程组

右击测试计划 → 添加 → 线程(用户) → 线程组

我的笔记本性能差，所以只设定了10个线程

2.2. 配置数据库连接串

右击测试计划 → 添加 → 配置元件 → JDBC Connection Configuration

python 复制代码

"""MySQL"""
URL：jdbc:mysql://[IP]:[端口]/[数库名]  # jdbc:mysql://localhost:3306/mysql
Driver:com.mysql.jdbc.Driver

python 复制代码

"""Oracle"""
URL：jdbc:oracle:thin:@[IP]:[端口]:[数库名]  #jdbc:oracle:thin:@localhost:1521:orcl
Driver：oracle.jdbc.OracleDriver

python 复制代码

"""PostgreSQL"""
URL：jdbc:postgresql://[IP]:[端口]/[数库名]  # jdbc:postgresql://localhost:5432/postgres
Driver:org.postgresql.Driver

2.3. 构造简单业务

右击线程组 → 添加 → 取样器 → JDBC Request

简单的读语句（仅举例）

简单的写语句（仅举例）

2.4. 配置监听器

右击线程组 → 添加 → 监听器 → 聚合报告
右击线程组 → 添加 → 监听器 → jp@gc - Response Times Over Time
右击线程组 → 添加 → 监听器 → jp@gc - Transactions per Second

监听器主要开启 "聚合报告"、"吞吐量走势" 和 "响应时间走势"，对于 "查看结果树" 不建议配置。因为压测过程中业务会持续运行，在这期间开启 "查看结果树" 会不断返回响应信息，这对压力机的内存消耗很大。一般在保证错误率为0后，都会将 "查看结果树" 注释。

配置案例如下：

2.5. 执行测试

点击启动按钮

压测结束后先查看聚合报告

上图聚合报告输出的2行数据，这两行分别是自定义的 select 业务和 insert 业务。我们主要关心这几个指标：平均响应时间、95%响应时间、异常率、吞吐量。

响应时间以 ms 为单位，从上图看 select 业务95%响应时间为 164ms。这是因为业务非常简单，所以响应比较快，总的来说可以接受。insert 业务95%响应时间为 26ms，比 select 业务快6倍左右，这也是业务简单，所以响应较快。

吞吐量就是我们常说的TPS/s，每秒执行完成多少个事务。这里的吞吐量只有 113，是因为机器本身的原因（性能差）。mysql官网压测的tpc业务吞吐量能够达到n万每秒，所以不要参考我这里的值。

检查完整体性能后再来看看响应时间的走势

如上图，insert 业务整体的响应时间走势相对平稳，这是符合预期的。而 select 业务的响应时间持续增长，这显然不符合预期。这种情况下需要考虑2点：

硬件瓶颈：根据硬件瓶颈情况优化

业务问题：设计不合理

我这里是属于第2种情况，业务设计不合理。select 业务为：
sql 复制代码
SELECT * FROM t1;
由于使用 * 输出全部结果，随着 inser 业务持续运行会导致表数据越来越大，所以查询返回的行数越来越多，消耗内存也就越来越多，响应时间也就持续增长。

我这里只是为了举个例子，与真实业务差距很大，所以"业务"并不具备参考性。

吞吐量走势图如下：

吞吐量的走势与响应时间是相对的，每个业务耗时越长，那么每秒能够完成的事务就会更少，所以吞吐量就会持续下跌。

3. 业务并发分配

jmeter 的线程数是由线程组设定的，所以我们通过创建多个线程组来分配不同业务的并发数。例如：读写业务占比 7:3

我笔记本性能差，总共10个线程，所以直接给读业务7、写业务3。

需要注意：监听器报告要与线程组平级，如果只放在某个线程组下面则只会统计这1个线程组的信息

来看一下压测后的结果

【线程分布】读写 7:3

【吞吐量】读业务高于写业务

【聚合报告】读业务高于写业务