jmeter 压测数据库

当前版本：

jmeter 5.6.3
mysql 5.7.39

简介

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

文章目录如下

1. 怎么实现高并发

2. 配置压测的基本流程

2.1. 设置线程组

2.2. 配置数据库连接串

2.3. 构造简单业务

2.4. 配置监听器

2.5. 执行测试

3. 业务并发分配

1. 怎么实现高并发

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

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

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

聚合报告    # 查看整体性能指标
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

"""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

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 业务为：
SELECT * FROM t1;
由于使用 * 输出全部结果，随着 inser 业务持续运行会导致表数据越来越大，所以查询返回的行数越来越多，消耗内存也就越来越多，响应时间也就持续增长。

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

吞吐量走势图如下：