说到开发自己的性能测试平台,肯定想到的是Jmeter,因为开源的性能测试工具没有比它更强大的了,所以第一个想到的是怎么把它变成性能测试平台,很多人首先想到的是通过jenkins结合jmeter,我想那也只能叫调度平台,不能叫性能测试平台。通过对Jmeter和Java快速开发框架的深入了解,我发现做一个自己的性能压测平台是可行的,而且网上也有人正在做。开发的过程肯定是无限的踩坑(开源的东西就这样),相对收获来说应该值的。以下是我针对开源的Java快速开发框架和别人实现的部分成品,再结合JMeterEngine的深入学习,梳理的平台架构:
以下是主要的技术选型及说明:
- 核心框架:Spring Boot 1.5
- 安全框架:Apache Shiro 1.3
- 视图框架:Spring MVC 4.3
- 持久层框架:MyBatis 3.3
- 定时器:Quartz 2.3
- 数据库连接池:Druid 1.0 (阿里开源)
- 日志管理:SLF4J 1.7、Log4j
- 页面交互:Vue2.x
- 前端监控:ECharts 3.8
- 压测内核(即JMeterEngine):Apache JMeter 4.0
- 脚本调用内核:Apache Commons Exec 1.3
- 远程执行命令:Jcraft 0.1.54
选用的快速框架是经量级的,而且是方便快速部署的:
【renren-fast开发框架】,具体可以上网获取:https://www.renren.io/guide/
性能测试平台的项目结构:
stress-test
├─doc 项目SQL语句
│
├─common 公共模块
│ ├─aspect 系统日志
│ ├─exception 异常处理
│ ├─validator 后台校验
│ └─xss XSS过滤
│
├─config 配置信息
│
├─modules 功能模块
│ ├─api API接口模块(APP调用)
│ ├─job 定时任务模块
│ ├─oss 文件服务模块
│ ├─sys 权限模块
│ └─test 压测模块
│
├─RenrenApplication 项目启动类
│
├──resources
│ ├─mapper SQL对应的XML文件
│ ├─static 第三方库、插件等静态资源
│ ├─views 项目静态页面
│ └─application.yml 环境配置
平台已实现的部分功能:
(1)用例管理:
用例管理支持jmx脚本的上传和参数化文件及测试附件的上传,一个用例创建一个目录(脚本、参数文件、附件、测试报告都在同一用例下保存)。删除用例时会自动删除用例下所关联的脚本,并一并删除已同步到各个节点的文件。
(2)脚本文件管理
每个脚本具有启动和停止压测线程的功能(具有状态标识),每个参数化文件或附件具有同步到各个节点的功能(同步完成后标识为同步成功)。
脚本文件除了启动和停止功能,还能配置是否开启报告生成和是否开户前端监控,监控为echarts图形监控,如下:
调用脚本进行压测的方法分为两种:
压测模式 | 调用模块 | 特点 | 优缺点 |
脚本调用模式 | Apache Commons Exec | 相当于通过远程执行jmeter命令调用脚本,完全依赖于jmeter bin目录 | 优点:实现简单,无需过多编程; 缺点:无法多线程控制,无法开启echarts监控,完全依赖本地Jmeter终端 |
引擎调用模式 | JMeterEngine | 用的是Jmeter压测内核,通过runTest方法开启压测线程,通过stopTest方法结束压测线程 | 优点:更加轻量级,多线程控制,支持单独停止某个脚本的测试,支持echarts监控,支持个性化扩展开发; 缺点:需要依赖更多编程实现 |
(3)测试报告管理
默认执行脚本过程中,生成了CSV报告,通过【生成报告】按钮,触发将csv报告转换成html DashBoard(这一步也是通过Commons Exec调度jmeter命令完成):
(4)分布式节点管理
分布式节点管理通过Jcraft远程执行linux命令,来启动或是停止各节点的Jmeter-server,启动命令格式如下:
//启动节点
String enableResult = ssh2Util.runCommand(
"cd " + slave.getHomeDir() + "/bin/testCases/" + "\n" +
"sh " + "../jmeter-server -Djava.rmi.server.hostname="+slave.getIp());
如果是禁用节点,就是通过远程执行杀进程的命令:
ssh2Util.runCommand("ps -efww|grep -w 'jmeter-server'|grep -v grep|cut -c 9-15|xargs kill -9");
这种方式挺方便,省了在多台linux节点机上,手动去连接和启动jmeter(分布节点越多越显得方便快捷)。
另外跟原来相比,分布式节点管理增加了校准功能,就是为了解决节点因为人为因素停了,而管理端不能及时的作出判断,现在通过校准可以将后台节点的进程状态跟前台同步一次(避免进程异常关闭或错误启动),目前不是自动校准。因为无论是实时监听端口还是定时校准,效率都不是最好的。以后可以尝试在压测过程中添加监听机制,来实时监测节点状态,而非压测时段就通过手动点击校准即可,这样会相对经济一些。
(5)监控扩展(Grafana+InfluxDB)
由于我在以前的一篇文章中写过有关Grafana+InfluxDB与Jmeter的监控(关于Jmeter长时间压测的可视化监控报告),可以直接拿过来集成使用。集成的方式是开启Grafana的匿名登录(在defaults.ini中配置),到官网下一个Jmeter的监控视图JSON模板导入,同时以跳转的方式将Grafana嵌入到平台的iframe中。
var URL_IP = parent.location.host;
var URL_PORT = parent.location.port;
window.location = "http://"+URL_IP.replace(":"+URL_PORT,"")+":3000/d/joulMbxmz/apache-jmeter-dashboard?orgId=1";
另外可以将Grafana和InfluxDB及一键启动脚本与性能压测平台一起部署,实现在部署层面上进行集成和无缝对接使用。
写到这我们的性能压测平台前期部分基本介绍完了,还有些功能未开始开发,比如像阿里云PTS的压测场景配置,这比较复杂,相当于是把脚本的场景设置移到WEB界面上,另外还要结合定时器进行脚本的灵活调度(发起压测、结束压测、持续时间、测试周期等),目前来看还没想好怎么实现。
而且目前出现了一些BUG,大部分都是由于Jmeter本身的局限性和稳定性引起的(比如长时间压测的监控稳定性问题),所以还任重道远......
更正说明:写这篇文章的时候,阿里云的PTS刚刚能支持原生jmeter(但前提是有项目支持你花这钱),也就是能支持websocket的压测,具体使用说明他们也提供了教程:https://help.aliyun.com/document_detail/93627.html?spm=5176.7946858.1219570.3.4ced572dQgCraE
版权声明:本文为博主原创文章,转载请附上博文链接!https://blog.csdn.net/smooth00/article/details/83380879