文章目的
作者是Java后端程序员,在测试方面属于零基础测试人员。
在使用jMeter对即将上线的项目进行压测时,遇到了很多问题。于是边学习,边总结。最终目的是:能够设计一个合理的测试方案,并得到一份测试报告。
一、测前准备
token问题
问题:接口需要登录后获取token才能访问、登录接口需要对密码进行RSA加密、jMeter跨线程组无法读取token变量。
- 先调用登录接口,并解析响应。
- 使用jmeter的前置处理器进行RSA加密,并获取token;
- 使用后置处理器提取响应字段中的token,并存入CSV文件;
- 前置处理器:进行RSA加密
- 后置JSON提取器:提取token
压力机性能问题
问题:个人电脑无法给服务器足够的压力——可能是性能不够、可能是网速太慢;
解决:使用分布式压测。多台机器共同给服务器上压力,并将各自的压测结果汇总在一起。
参考:Linux下Jmeter安装与实战_linux上安装jmeter的安装路径在批量执行是取到哪一级-CSDN博客
参考:Jmeter-分布式压测配置及常见问题(一文全)_jmeter压测-CSDN博客
二、压测方案
- 本次采用:
- 阶梯压测:逐步提升压力,例如从1000、1500、2000、3000、4500并发用户下,分别进行30分钟的压力测试,根据汇总图表,分析系统对用户数量的支持情况。
- 混合接口测试:假设系统中各个模块分别有一定比例的用户正在访问,不同的页面有不同的访问频次。用户在访问不同的页面时有不同的思考时间(思考要点击哪个按钮)和停留时间(查看页面内容)。最终设计出混合接口测试方案,并得到jmx文件放在服务器的bin路径下。
三、测试环境配置
参考:超全面!性能测试:JMeter分布式压测环境部署_jmeter分布式部署-CSDN博客
参考:jmeter更改报告的保存频率_jmeter 更改granularity-CSDN博客
操作系统 | IP地址 | 类型 | 环境 |
---|---|---|---|
Centos(APP-1) | xx | Controller(控制机) | jmeter-5.6.3,JDK21.0.2 |
Centos(APP-2) | xx | Slave(执行机) | jmeter-5.6.3,JDK21.0.2 |
Centos(APP-3) | xx | Slave(执行机) | jmeter-5.6.3,JDK21.0.2 |
启动准备:
# 后台启动(在jmeter安装路径的bin目录下)
nohup jmeter-server &
# 验证启动
ps -ef | grep jmeter
压测方案执行:
# 在Controller机器的jmeter安装路径的bin目录下执行
# 1:1000线程*3台主机=3000用户
# 混合测试最最终版-阶梯1.jtl: jtl文件,可导入jmeter进行分析
# 混合测试最最终版-阶梯1-结果:可视化文件的文件夹
jmeter -n -t ./混合测试最最终版-阶梯1.jmx -r -l 混合测试最最终版-阶梯1.jtl -e -o ./混合测试最最终版-阶梯1-结果
# 2:1500线程*3台主机=4500用户
jmeter -n -t ./混合测试最最终版-阶梯2.jmx -r -l 混合测试最最终版-阶梯2.jtl -e -o ./混合测试最最终版-阶梯2-结果
# ……………… 其他方案
三、压测结果分析
压测结果将在汇总后,由jmeter自动生成,放置在主机jmeter安装路径bin目录下的文件夹内。
不做展示:但认为可主要关注:每秒响应数量、平均响应时间、活跃线程数量、每秒点击(hits)数量、响应时间百分位、响应时间VS线程数。
本人本次测试系统,发现压力主要来自于对单独资源频繁访问时的MySQL行锁(通过加判断条件或先存入缓存解决)、数据库单库写压力(上读写分离不能解决,暂时这样,可考虑云数据库),以及一些其他问题,工期小的修改、大的先不管。