Jmeter-JDBC连接测试
1 环境配置
1.1 测试环境准备
数据库:Oracle 11g,库名:orcl;
Jmeter:jmeter-5.1.1安装在win10系统下(到 http://jmeter.apache.org/ 下载JMeter压缩包,无需安装解压即可,点击bin目录下的jmeter.bat文件即可运行Jmeter)
JDBC驱动:找到ojdbc 14.jar并将其复制粘贴到D:\Program Files\apache-jmeter-5.1.1\lib目录下
1.2 测试计划
打开测试计划,添加JDBC驱动:
1.3 线程组
添加一个线程组,并配置页面。
在取样器错误后要执行的动作:在线程内的采样器失败后,接下来做什么。
1) 继续:继续执行接下来的操作;
2) Start Next Loop:忽略错误,执行下一个循环;
3) 停止线程:退出该线程(不再进行此线程的任何操作);
4) 停止测试:等待当前执行的采样器结束后,结束整个测试;
5) Stop Test Now:直接停止整个测试。
线程属性(5个设置项)
1) 线程数:模拟的用户数量;
2) Ramp-up Period(in seconds):达到指定线程数所需要的时间。举例:线程数设置为50,此处设置为5,那么每秒启动的线程数 = 线程数50/5 = 10;
3) 循环次数:选中“永远”,则一直循环下去;
4) Delay Thread creation until needed:(延迟创建线程直到需要):当线程需要执行的时候,才会被创建。如果不选择这个选项,那么,在计划开始的时候,所有需要的线程就都被创建好了;
5) 调度器:详见下文“调度器配置”。
调度器配置:全部都在“调度器”复选框被选中的前提下,下面的选项才会生效。
1) 持续时间(秒):在此选项填入N,说明这个计划,从某个开始时间算起,执行N秒后结束。(会忽略“结束时间”的选项);
2) 启动延迟(秒):在此选项填入N,手动点击开始执行计划,然后延迟N秒后,计划才真正开始执行。(会忽略“启动时间”的选项);
3) 启动时间:当点击开始测试时,将等到此处填写的启动时间,然后真正开始测试;
4) 结束时间:当开始测试时,将等到指定的开始时间开始测试,然后会停在此处填写的时间点结束。
1.4 JDBC Connection Configuration
添加配置元件“JDBC Connection Configuration”,并配置页面。
Variable Name Bound to Pool:
Variable Name:数据库连接池的变量名,之后JDBC request可以通过选择不同的连接池名来选择不同的数据库连接。变量名不能重名。
Connection Pool Configuration:JDBC连接池配置,一般使用默认值就可以。
1) Max Number of Connections:数据池允许的最大连接数,通常该值设置为0,意思是每个线程都使用单独的数据库连接,例如,配置在两个线程间不共享。如果你确实想共享连接池,那么最大连接数应当和线程数一样,以便线程不用互相等待;
2) Max Wait (ms):在连接池中取回连接的最大等待时间,如果超过改时间,将抛出一个错误;
3) Time Between Eviction Runs (ms):数据库空闲连接的回收时间间隔。回收时,会将将空闲连接物理性的关闭掉。若为非正数,则空闲连接回收器不停运行;
4) Auto Commit:自动提交。有三个选项,true、false、编辑(自己通过jmeter变量值设置)。选择true后, 每条sql语句就是一个事务,执行结束后会自动提交;否则不会提交,需要自己手动提交;
5) Transaction Isolation:数据库事务隔离的级别设置,有6个选项(对JMX加解密):TRANSACTION_NODE:事务节点;TRANSACTION_READ_UNCOMMITTED:事务未提交读;TRANSACTION_READ_COMMITTED:事务已提交读; TRANSACTION_SERIALIZABLE:事务序列化;DEFAULT:默认;TRANSACTION_REPEATABLE_READ:事务重复读;编辑。
Connection Validation by Pool,连接池有效性验证配置部分:这是Jmeter用来检验数据库连接是否有效的一种机制,超过5秒没有使用的话,就会用validation query去测试下这个连接是否有效,一般使用默认就可以。
1) Test While Idle:是否在空闲时进行连接有效性验证。Validation Quary被用来验证连接的有效性;
2) Soft Min Evictable Idle Time(ms):数据库连接池中的连接至少闲置多久才能被回收。额外的条件是,在连接池中至要保留有minIdle个连接
3) Validation Query:一个验证数据库仍然响应的简单查询语句。默认是JDBC驱动的 ‘isValid()’ 方法,它适合于很多数据库。可以通过jmeter.properties中jdbc.config.check.query属性设置默认的验证sql语句,有10个选项:Hsqldb select 1 from INFORMATION_SCHEMA.SYSTEM_USERS;Oracle select 1 from dual;DB2 select 1 from sysibm.sysdummy1;MySQL select 1;Microsoft SQL Server (MS JDBC driver) select 1;PostgreSQL select 1;Ingres select 1;Derby values 1;H2 select 1;Firebird select 1 from rdb$database。
Database Connection Configuration,数据库连接配置部分。
1) Database URL: 数据库的连接字符串;
2) JDBC Driver class:驱动程序类的完全限定名;
3) Username:连接数据库的合法用户名;
4) Password:用户对应的口令。
1.5 JDBC Request
添加取样器“JDBC request”,并配置页面。
Variable Name Bound to Pool:
Variable Name:数据库连接池的名字,需要与JDBC Connection Configuration的Variable Name Bound Pool名字保持一致。
SQL Query:
1) Query Type:JDBC Request可以发送的请求类型,目前有10类:Select Statement;Update Statement - use this for Inserts and Deletes as well; Callable Statement;Prepared Select Statement;Prepared Update Statement - use this for Inserts and Deletes as well;Commit;Rollback;Autocommit(false);Autocommit(true);Edit - this should be a variable reference that evaluates to one of the above;
2) Query:填写的sql语句,未尾不要加“;”;
Parameter values:参数值。
Parameter types:参数类型,(比如varchar、tinyint(m)、smallint(m) )。
Variable names:保存sql语句返回结果的变量名。
Result variable name:创建一个对象变量,保存所有返回的结果。
Query timeout:查询超时时间。
Handle result set:定义如何处理由callable statements语句返回的结果,有四个选项:Store as String;Store as Object;Count Records;编辑。
1.6 HTTP请求默认值
该组件可以为我们的http请求设置默认的值。假如,我们创建一个测试计划有很多个请求且都是发送到相同的server,这时我们只需添加一个 Http request defaults组件并设置“Server Name or IP”,然后添加多个http请求且不设置”server name or ip”,这些http请求会默认使用Http request defaults组件设置的值。
1.7 BeanShell 后置处理程序
添加后期处理器BeanShell PostProcessor,用来把查询的结果显示在log上。如果不需要设置postprocessor观察数据,可以直接添加监听器运行。
在利用jmeter进行接口测试或者性能测试的时候,我们需要处理一些复杂的请求,此时就需要利用bean shell脚本了,Bean Shell是一种完全符合Java语法规范的脚本语言,并且又拥有自己的一些语法和方法,所以它和java是可以无缝衔接的。bean shell本身自带的一些内置变量和一些方法。JMeter在其Bean Shell中内置了变量,用户通过这些变量与JMeter进行交互。
1) log 打印日志,写入信息到jmeber.log文件。
2) SampleResult 获取SampleResult对象,能通过这个对象获取想要的信息。
3) Response 获取Response对象,能通过这个对象获取响应信息。
4) Failure 查看接口调使用能否成功,假如返回false是成功的,true是失败的。
5) FailureMessage 失败信息,没有设置的时候失败信息是空的,能set这个信息。
6) ResponseData 获取response body类型是byte[]。
7) ResponseCode 返回接口code成功是200。
8) ResponseMessage 获取msg成功是OK。
9) ResponseHeaders 获取接口服务端返回的头部信息。
10) RequestHeaders 获取用户端请求的头部信息。
11) SampleLabel 获取接口请求的名称。
12) SamplerData 获取请求的url和body。
13) ctx代表上下文信息,能直接用。
14) vars即JMeterVariables,操作jmeter变量,这个变量实际引用了JMeter线程中的局部变量容器(本质上是Map),常用方法:
a) vars.get(String key):从jmeter中获得变量值;
b) vars.put(String key,String value):数据存到jmeter变量中;
15) prev 获取前面的sample返回的信息,常用方法:
a) getResponseDataAsString():获取响应信息。
b) getResponseCode() :获取响应code。
2 JDBC连接测试
2.1 测试场景
场景描述:
通过将线程数分别设置为100、200、300,以实现对100个用户同时对JDBC发出查询指令,200个用户同时对JDBC发出查询指令,300个用户同时对JDBC发出查询指令的模拟。
2.2 测试用例
测试需求 | 测试过程说明 | 过程标引 |
查询 | 以100线程数查询表格所有信息记录 | Select 100 |
以200线程数查询表格所有信息记录 | Select 200 | |
以300线程数查询表格所有信息记录 | Select 300 |
2.3 测试结果
2.3.1 100个用户同时对JDBC发出查询指令
a) 察看结果树
jmeter中最常用的监听器,可以看到请求的发送和返回信息。
b) 图形结果
图表底部参数的含义如下:
样本数目:总共发送到服务器的请求数;
最新样本:代表时间的数字,是服务器响应最后一个请求的时间;
吞吐量:服务器每分钟处理的请求数;
平均值:总运行时间除以发送到服务器的请求数;
中间值:代表时间的数字,有一半的服务器响应时间低于该值而另一半高于该值;
偏离:服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布。
分析:在此情况下数据库管理系统服务器的平均值为588,中间值为545,响应时间差异大。响应性能不稳定。
c) 聚合报告
Label:数据请求方式,图上是数据库连接;
#samples:向服务器发送的请求数目;
Average:总运行时间除以发送到服务器的请求数;
Median:图形报表中的中间值,是代表时间的数字,有一半的服务器响应时间低于该值而另一半高于该值;
90%line:是指90%请求的响应时间比所得数值还要小;
95%line:是指95%请求的响应时间比所得数值还要小;
99%line:是指99%请求的响应时间比所得数值还要小;
Min:是代表时间的数字,是服务器响应的最短时间;
Max: 是代表时间的数字,是服务器响应的最长时间;
Error%:请求的错误百分比;
Throughput:图形报表中的吞吐量,这里是服务器每单位时间处理的请求数,注意查看是秒或是分;
KB/sec:是每秒钟请求的字节数。
分析:本次测试场景运行100线程,平均响应时间=558ms,统计意义上的响应时间中值=545ms,所有线程中90%的线程响应时间都小于1000ms,所有线程中95%的线程响应时间都小于1064ms,所有线程中99%的线程响应时间都小于1086ms,响应最小时间=20ms,响应最大时间 =1122ms,出错率 = 0,吞吐量为每秒84个请求。
2.3.2 200个用户同时对JDBC发出查询指令
a) 察看结果树
b) 图形结果
分析:在此情况下数据库管理系统服务器的平均值为102,中间值为3,响应时间差异较大。响应性能较不稳定。相应的,响应时间有所增加。
c) 聚合报告
分析:本次测试场景运行200线程,平均响应时间=102ms,统计意义上的响应时间中值=3ms,所有线程中90%的线程响应时间都小于356ms,所有线程中95%的线程响应时间都小于435ms,所有线程中99%的线程响应时间都小于514ms,响应最小时间=1ms,响应最大时间 =677ms,出错率 = 0,吞吐量为每秒163.4个请求。
2.3.3 300个用户同时对JDBC发出查询指令
a) 察看结果树
b) 图形结果
分析:在此情况下数据库管理系统服务器的平均值为2,中间值为2,响应时间明显减小。响应性能稳定。随着用户的增加,响应时间变长。
c) 聚合报告
分析:本次测试场景运行300线程,平均响应时间=2ms,统计意义上的响应时间中值=2ms,所有线程中90%的线程响应时间都小于3ms,所有线程中95%的线程响应时间都小于3ms,所有线程中99%的线程响应时间都小于3ms,响应最小时间=1ms,响应最大时间 =5ms,出错率 = 0,吞吐量为每秒235.8个请求。
3 测试结果
分析:
根据表中数据可知,随着用户请求数量的增加,数据库服务器的每分钟处理请求数即吞吐量也在逐步增加,平均响应时间大幅减少。
经过分析可得出以下结论:
数据库服务器的系统性能随着用户数量的增加而大大提高,此数据库服务器的系统性能良好,测试的数值在其承受范围内。