jmeter压测mysql数据库

文章目录如下

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 业务持续运行会导致表数据越来越大，所以查询返回的行数越来越多，消耗内存也就越来越多，响应时间也就持续增长。

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

        

吞吐量走势图如下：

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

        

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

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

        

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

        

来看一下压测后的结果

【线程分布】读写 7:3

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

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

————————————————

                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
                        
原文链接：https://blog.csdn.net/m0_61066945/article/details/135788765