性能系列文章目录
欢迎大家关注「海拉鲁知识大陆」 多交流不迷路
第五章-JMeter脚本之GaussDB数据库压测
在性能测试过程中,应用层有日志打印是sql执行慢,数据库层自身也有慢查询日志,需要逐个单独对数据库层进行压测分析
JMeter原生组件以及支持对数据库的批量操作,大体步骤如下:
- 添加JDBC驱动程序:将JDBC驱动程序添加到JMeter的/lib目录下。
- 配置JDBC连接字符串:在JMeter中,使用JDBC Connection Configuration元件配置数据库连接信息,包括URL、用户名、密码等。
- 编写JDBC请求:使用JDBC Request元件编写SQL语句,并在JMeter中执行。
1 添加JDBC驱动程序
目前我们使用的是GuassDB,使用对应驱动是postgresql的驱动(这里避坑一下,开始以为是使用gaussdbjdbc.jar:主类名为“com.huawei.gaussdb.jdbc.Driver”结果是不行的)。将JDBC驱动程序(和研发保持一致的版本jar包opengauss-jdbc-2.0.0)添加到JMeter的/lib目录下。
2 配置JDBC连接字符串
添加JDBC Connection Configuration元件配置数据库连接信息
注意点:
Variable Name for created pool:链接池变量名,在数据库操作取样器中使用(就是初始化类似请求头)
这里链接池配置数量最好和应用层服务的设置保持一致,如大小和超时时间
Database Connection Configuration:数据库链接配置
这里还是postgresql驱动(前面就搞错成gaussdbjdbc链接失败)
如:jdbc:postgresql://192.168.21.115:5432/biz_db
和对应用户名/密码
3 编写JDBC请求
使用JDBC Request元件编写SQL语句
注意点:
Variable Name bound to pool:指定前创建的链接池变量名
Query Type: 字段用于指定要执行的SQL查询类型
- Select Statement:执行一个SQL SELECT查询,用于从数据库中检索数据。
- Update Statement:执行一个SQL UPDATE查询,用于修改数据库中的数据。
- Insert Statement:执行一个SQL INSERT查询,用于向数据库中插入新数据。
- Delete Statement:执行一个SQL DELETE查询,用于从数据库中删除数据。
- Callable Statement:执行一个SQL存储过程或函数。
- Prepared Select Statement:执行一个预编译的SQL SELECT查询,用于从数据库中检索数据。
- Prepared Update Statement:执行一个预编译的SQL UPDATE查询,用于修改数据库中的数据。
Query: 字段用于输入要执行的SQL语句(我们应用层使用是预编译模式所以我们是Prepared Statement,使用参数占位符)
Parameter values:预编译模式下参数数量和占位数一致(英文逗号分隔),可以使用Jmeter${}作参数化
Parameter types: 参数类型和占位数一致(英文逗号分隔),支持VARCHAR、INTEAGER等(注意${}参数化就VARCHAR因为它就是个String类型)
Variable names:查询结果的参数化变量名(英文逗号分隔),即返回结果可以根据列返回后面使用
Result variable name:结果集变量名
预编译
这里简单聊一下数据库预编译,目前我们应用层主要是使用预编译模式,我们先了解下SQL的执行过程
1 词法分析:将SQL语句分解成一个个token(关键字、标识符、运算符),然后对token进行分类和解析,生成相应的数据结构。
2 语法分析:根据SQL语法检测规则检查语法是否正确,并成成语法树。
3 语义分析:遍历语法树,确定表和列等信息,同时检查语义的正确性。
4 优化处理:使用优化器对SQL语句进行处理和优化,比如执行计划、索引等。
5 执行计划:使用执行计划生成器生成SQL语句的执行计划,比如数据的访问方式,索引的使用方式等。
6 引擎执行:将执行计划发送给相应的数据库引擎进行处理,执行计划被翻译成底层的操作指令,执行数据扫描、索引查找、排序、分组等操作。
7 返回数据:将执行结果返回给客户端,比如查询结果集或操作结果
在这里,我们粗暴的把执行过程理解成两大步,即:先编译SQL语法结构
(1-3步),再执行SQL语句(4-7步)。
那预编译SQL在数据库DBMS直接运行编译后的SQL语句这样就省略了(1-3步)所以执行效率更高、性能更快。
4 SQL压测优化
整理待测的SQL脚本进行400线程进行压测5min
- 第一次执行:tb_pdf_sign语句有超过10s出现错误率,吞吐量只有82
- 第二次执行:tb_pdf_sign语句吞吐量提升3540,优化索引和数据库服务器核数
- 第三次执行:tb_pdf_sign语句吞吐量提升7801,优化并行执行计划
- 第四次执行:tb_pdf_sign语句吞吐量提升8636,空闲时间执行(无其他人使用环境情况)
以上是基于在性能测试中已发现的慢SQL的进行压测调优,这里我们思考一下,如何在SIT环境、UAT环境、自动化环境、性能环境等做到无人值守SQL性能看护呢?