压力测试,我们针对比较关键的接口,可以进行相应的压力测试,主要还是测试看看接口能抗住多少的请求数,TPS稳定在多少,也就是吞吐量多少
bin目录下的jmeter.properties
sampleresult.default.encoding=utf-8
如果说公司内网有做代理,那么就需要配置公司的代理服务,这样才能访问网络,完成后面我们需要的安装jmeter插件实现梯式线程压测的线程与监听器(TPS压测图等,带jp@的监听器)的引用。如果网络不通,是无法安装好对应的插件的,完成下面方法二的梯式递增线程的压测方式
jmeter.bat -H proxy.xxx.com -P 8080 -u 账号 -a 密码
bin目录下的 system.properties文件
//具体格式看内网情况
http.proxyHost=proxy.xxx.com
https.proxyHost=proxy.xxx.com
http.proxyPort=8080
https.proxyPort=8080
下载证书
步骤1:使用chrome浏览器打开jmeter插件官网,链接:https://jmeter-plugins.org 。
步骤2:在地址栏点击锁图标,下拉菜单点击“连接是安全的”,次级菜单点击“证书有效”。
步骤3:在弹出的证书信息页面,点击“证书路径”,选择根证书“xxxCA”,点击“查看证书”。
步骤4:在弹出的证书信息页面,导出Base64编码文件,选择目录放好,用于后续导入D:\xxxCA.cer
导入证书
步骤1:以管理员身份运行windows命令行工具,然后切换到jdk安装目录下的jre\lib\sercurity目录。
例如 cd /D C:\Program Files\jdk1.8.0_272\jre\lib\security
注意:务必管理员身份运行,否则后续步骤导入证书到密钥库会失败,提示 “keytool 错误: java.io.FileNotFoundException: cacerts (拒绝访问。)”。
步骤2:输入以下命令,导入证书。 证书路径就是前面下载的路径
keytool -import -alias CA -keystore cacerts -file D:\xxxCA.cer
输入密钥看库口令: changeit
是否信任次证书:y
步骤3:输入以下命令,检查证书是否导入成功。
keytool -list -keystore cacerts -alias CA
操作:这里我有两种模式去压测
是直接创建 线程组,然后把请求,请求头,报告,TPS压测图等都创建出来,用来可视化观察压测过程数据,吞吐量的值,可以在聚合报告看
这种方法,比较常用,在线程组中进行设置线程数,每秒执行,那么这个线程数一般就是业务要求的并发用户数,也就是同一时刻,能支持多少用户请求,基于的是系统的用户量,业务的要求,来指定的数值
还是一种,就是不知道用户体谅,比如系统用户比较少,不太清楚并发情况,那么可以用插件,梯式增加线程数,直到我们的吞吐量稳定在一个区间,可以通过TPS压测图来看到,随着一开始线程从0增加,TPS(每秒事务数)在递增,达到一定的线程数时,也就来到了系统的瓶颈,TPS开始趋于稳定,然后线程数再增加,那么TPS可能就是下降了,说明在峰值稳定区间,就是系统能支撑住最佳的一个并发数值了。
这种方式适合寻求:如何找到系统的最大并发量。此时,需要我们先做负载测试(负载测试概念:简单来说:逐步增加并发用户数,找出被测系统的最大可接受的并发用户数,并考察系统性能的变化),通过逐步加压,来找到最大并发用户数。那么当我们找到一个区间,怎么找到具体的值呢?
在区间中逐步增加步长,出现以下任意现象时,即是最大并发用户数:
1.出现连续报错
2.平均响应时间超过1.5秒(1.5秒是行业标准)
3.tps出现下降趋势
1:安装jmeter 管理插件:
下载地址:https://jmeter-plugins.org/install/Install/,将下载下来的jar包放到jmeter文件夹下的lib/ext路径下,然后重启jmeter。
2:接着打开 选项-Plugins Manager-在Available Plugins中找到Custom Thread Groups,jdbc - Standard Set 安装这两个插件,然后点击右下角图标进行安装重启,安装完成后就可以在Installer Plugins列表中看到,那么接下来就可以执行创建一个线程梯式增加组了
选择”jp@gc - Stepping Thread Group“,插件
默认设定值如下:
jp@gc - Stepping Thread Group填写数据,场景为在5秒内增加10个并发用户数,并运行30秒,再继续在5秒内增加10个并发用户数,重复循环,直至并发用户数达到100个后运行脚本60秒。然后在每1秒内减少5个并发用户数,直到减为0,结束脚本的运行
这里比较简单,类似Postman
注意点在于,我们测试接口的时候,接口一般都是需要认证用户登录,这里我比较简单的去添加一个请求头,放了一个Cookie,这里的Cookie是我在登录系统中,在浏览器控制台中的请求头找到的Cookie信息复制出来的,时间一久了会失效,就需要重新在系统上请求,重新获取,这里比较合理的做法应该是要先创建一个登录请求,然后关联我们用户信息放在一个CSV表格导入到Jmeter中,配置相关信息去获取,但是这种比较麻烦,先不去关注。
察看结果树、汇总报告、聚合报告、汇总图、TPS(每秒事务数)、RT(响应时间)、AT(活动线程)
吞吐量可以在聚合报告看到,具体的测试图,可以看看TPS
TPS: 这里刚好出现的异常,当然具体要看是什么异常,我这里测试的时候是刚好cookie失效了。如果说是因为线程过大了,报异常,那么TPS就会下降,中间会有一段峰值趋于稳定,就是这个接口所能抗住的一个最佳的并发量了。然后我们可以接着再去调整最大线程数,重新反复压测,直到获得一个最佳的并发数。
2分多钟时,TPS达到峰值,大概就是60-75,可以接着把线程数从100调整到这个区间,重新进行压测,看看吞吐量会不会有变化
2分多钟时,接口的响应时间也是比较可观 每秒请求是800ms左右
汇总报告,吞吐量在51,这是一个平均值,整个测试下来的均值
基于上面的测试过程,可以得出一个大致的结论,这个接口的并发量大概是60-75区间