告知：目前已做了兼容性的改造，支持适配Jmeter5.4.1的编译和运行！

很早就想要一套属于自己的性能压测平台，原因是使用了阿里云的性能测试PTS，就挺羡慕能有一个这样的性能测试平台，但毕竟人家的东西我们高攀不起（要钱的），而且阿里云的性能测试平台是不支持多种协议的（比如我有一个项目要用websocket测试，结果人家就支持http压测）。

       说到开发自己的性能测试平台，肯定想到的是Jmeter，因为开源的性能测试工具没有比它更强大的了，所以第一个想到的是怎么把它变成性能测试平台，很多人首先想到的是通过jenkins结合jmeter，我想那也只能叫调度平台，不能叫性能测试平台。通过对Jmeter和Java快速开发框架的深入了解，我发现做一个自己的性能压测平台是可行的，而且网上也有人正在做。开发的过程肯定是无限的踩坑（开源的东西就这样），相对收获来说应该值的。以下是我针对开源的Java快速开发框架和别人实现的部分成品，再结合JMeterEngine的深入学习，梳理的平台架构：



该平台已经开源（无Java经验的测试人员慎入，以免烦扰）： https://gitee.com/smooth00/stressTestSystem

针对小白，提供了一键部署包：https://gitee.com/smooth00/stressTestSystem/releases，只要安装了JDK1.8，下载安装包stressTestSystem-min-5.1.1.rar 解压后，通过批处理脚本就能运行压测平台。一键部署包所对应的Docker镜像文件可以直接pull到：docker pull smooth00/stresstest-system

Docker部署方案参考：https://gitee.com/smooth00/stressTestSystemDocker

以下是主要的技术选型及说明：

核心框架：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（现已支持5.1.1、5.4.1版本）
	
脚本调用内核：Apache Commons Exec 1.3（弃用）
	
远程执行命令：Ganymed build210
	
批量上传组件：bootstrap-fileinput v4.5.2
	
JVM内部缓存：Guava 18.0
选用的快速框架是经量级的，而且是方便快速部署的：

【renren-fast开发框架】，具体可以上网获取：https://www.renren.io/guide/

性能测试平台的项目结构：

stress-test
├─doc  项目SQL语句
│
│─lib  项目引用外部jar包（默认没有）
│
├─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）脚本文件管理

每个脚本具有启动和停止压测线程的功能（具有状态标识），每个参数化文件或附件具有同步到各个节点的功能（同步完成后标识为同步成功）。



支持脚本文件在线修改（基于jmx文件的模板化编辑）：



启动脚本可以选择指定节点压测，只要空闲状态的节点都可以选择，真正实现并行任务执行：



 脚本文件除了启动和停止功能，还能配置是否开启报告生成和是否开启前端监控，监控是echarts图形监控，如下：



调用脚本进行压测的方法分为两种：

压测模式
			
调用模块
			
特点
			
优缺点
		
脚本调用模式
			
Apache Commons Exec
			
相当于通过远程执行jmeter命令调用脚本，完全依赖于jmeter bin目录
			
优点：实现简单，无需过多编程；
缺点：无法多线程控制，无法开启echarts监控，完全依赖本地Jmeter终端
		
引擎调用模式
			
JMeterEngine
			
用的是Jmeter压测内核，通过runTest方法开启压测线程，通过stopTest方法结束压测线程
			
优点：更加轻量级，多线程控制，支持单独停止某个脚本的测试，支持echarts监控，支持个性化扩展开发；
缺点：需要依赖更多编程实现
		
另外支持将脚本添加到任务，用的是框架本身的任务管理，加上cron表达式生成器插件的应用，可以方便的实现脚本的定时任务创建，这样就能定时执行脚本（这个是LR所不具备的功能，一般可以用于接口的自动化测试）：



 （3）测试报告管理



报告生成模式
			
调用模块
			
特点
			
优缺点
		
Jmeter Home命令模式
			
GenerateReport ByScript
			
相当于通过执行jmeter命令调用报告，完全依赖于jmeter home目录
			
优点：实现简单，无需特别编程，直接调用；
缺点：无法多线程控制，无法多用户并发生成报告，完全依赖本地Jmeter_Home目录的配置
		
Web进程多线程模式
			
GenerateReportLocal
			
采用本地web进程来实现CSV报告文件转化成html模板报告
			
优点：更加轻量级，多线程控制，使用更加轻便，配置简单（不依赖于Jmeter Home的配置）；
缺点：需要依赖更多编程实现
		
默认执行脚本过程中，生成了CSV报告，通过【生成报告】按钮，触发将csv报告转换成html DashBoard（这一步也是通过Commons Exec调度jmeter命令完成），展示效果如下：



除了测试报告，还支持调试报告（显示接口请求信息，类似于Jmeter的查看结果树） ，原理是调用xls模板将JTL结果转为html报告（区别于测试报告是将CSV结果转为html报告），展示效果如下：



（4）分布式节点管理



分布式节点管理通过Ganymed远程执行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界面上，另外还要结合定时器进行脚本的灵活调度（发起压测、结束压测、持续时间、测试周期等），目前来看还没想好怎么实现。但是可以先实现线程组的在线管理：

（6）线程组管理



线程组管理的原理也不复杂，就是上传脚本时，通过dom4j递归扫描Jmx脚本（本质上是xml）的节点，获取线程组的配置节点参数，保存入库，然后在界面上修改和管理，改完还可以同步回Jmx脚本（也是通过dom4j对xml进行set配置）。目前实现的管理的线程组类别包括默认的ThreadGroup、jp@gc - Stepping Thread Group、jp@gc - Ultimate Thread Group，这三种已经算最常用的了。线程组管理的目的就是免去简单的线程配置（如并发数配置、线程组禁用）还要线下设置，设置完又要上传，另外脚本的线程组配置在平台界面上也能一目了然，避免又要临时打开Jmeter工具进行查看。

（7）压测节点监控【该功能未开源】



既然有了分布式节点管理，那边我们也可以做到对节点的分布式监控，在Influxdb-Grafana的基础上，引入telegraf来实现；我们通过界面上，加入监控开启和停止的按钮，再结合节点上部署的一些批处理命令，来实现一键启动监控代理。

启动和关闭的核心代码如下：

     /**
     * 批量切换节点的监控状态
     */
    @Override
    public void updateMonitorBatchStatus(List<Long> slaveIds, Integer monitorStatus) {
    	String execStr="";
        for (Long slaveId : slaveIds) {
            StressTestSlaveEntity slave = queryObject(slaveId);
            // 本机节点无需远程操作
            if ("127.0.0.1".equals(slave.getIp().trim())) {
            	Runtime r = Runtime.getRuntime();  
            	//执行本地操作系统命令，不关心返回结果，
        	    Process p = null;
				try {
					if(OS_NAME_LC.startsWith("windows")){
						if (StressTestUtils.ENABLE.equals(monitorStatus))
							execStr = "cmd.exe /c \""+StressTestUtils.getJmeterHome()+"\\telegraf\\start.cmd\" -a";
						else
							execStr = "cmd.exe /c taskkill /im telegraf.exe /f";					
					}else{
						if (StressTestUtils.ENABLE.equals(monitorStatus))
							execStr = "sh "+StressTestUtils.getJmeterHome()+"/telegraf/startUp.sh "+slave.getSlaveName();
						else
							execStr = "sh "+StressTestUtils.getJmeterHome()+"/telegraf/stop.sh "+slave.getSlaveName();	
					}
					p = r.exec(execStr);
					p.waitFor();
				} catch (Exception e) {
					// TODO Auto-generated catch block
					e.printStackTrace();
				} finally {
					if(null!=p){
						p.destroy();
						p=null;
					}
				}
				//更新数据库
	            slave.setMonitorStatus(monitorStatus);
	            update(slave);
            	continue;
            }
            //其他节点需要SSH远程连接
            SSH2Utils ssh2Util = new SSH2Utils(slave.getIp(), slave.getUserName(),
                    slave.getPasswd(), Integer.parseInt(slave.getSshPort()));
            // 避免跨系统的问题，远端由于都时linux服务器，则文件分隔符统一为/，不然同步文件会报错。
            String telegrafServer = slave.getHomeDir() + "/telegraf/telegraf";
            String md5Str = ssh2Util.runCommand("md5sum " + telegrafServer + " | cut -d ' ' -f1");
            if (!checkMD5(md5Str)) {
                throw new RRException(slave.getSlaveName() + " 监控模块出错！找不到telegraf启动文件！");
            }
            //如果是开启监控
            if (StressTestUtils.ENABLE.equals(monitorStatus)) {
            	//启动监控
            	execStr =
                        "sh " + slave.getHomeDir() + "/telegraf/startUp.sh " 
                        	  + slave.getSlaveName()+" "+stressTestUtils.getLocalIp();
            }else{
            	//禁用监控
            	execStr = "sh " + slave.getHomeDir() + "/telegraf/stop.sh";
            }
            String enableResult = ssh2Util.runCommand(execStr);
            logger.error(enableResult);

            if (!enableResult.contains("telegraf")) {
                throw new RRException(slave.getSlaveName() + " telegraf执行失败！请先尝试在节点机命令执行");
            }

            //更新数据库
            slave.setMonitorStatus(monitorStatus);
            update(slave);
        }
    }

       从代码我们也可以看出，我们将telegraf启动和配置文件都放置在jmeter节点的根目录下，这样能方便远程SSH调用，同时我们将监控平台的IP和节点名称也发送过去，并更新到telegraf.conf文件中，这样启动的telegraf进程就会将监控数据发回到我们的influxdb，并通过grafana监控到。以下是监控的效果：



       这样我们就实现了对压测机的监控（在测试过程中不对压测机监控是不合理的，特别是CPU、内存、网络IO等，万一出现测试机的性能瓶颈由于不能及时发现就会导致无用功），除了压测机的监控，我们可以由点及面，做出一个压测平台的监控服务平台，对被测服务端也进行监控。

（8）平台日志监控【该功能未开源】



       说是日志监控，目前只是实现了日志的前台展现功能，将info、debug、warn、error不同的日志级别用颜色标识。获取日志的方式是开通websocket通道，用spring-boot推送实时日志到前端页面显示，这种方式其实也没什么特别的，在网上能找到大把的实现方式，但其作用还是挺大的，平台运行或是压测过程中如果出现异常，直接在前台跟踪日志即可，没必要再跑到后台服务器上用tail命令跟踪了，易用性变强了。

（9）支持redis缓存测试数据并生成报告【该功能未开源】



通过redis缓存压测的监听数据，并自动生成报告（并套用自定义的报告模板），在速度上要远快于csv生成html报告，主要是为了解决测试报告文件太大生成报告太慢的问题（利用redis集群可以加大测试数据缓存的并发性），另一个好处是将自己需要的测试结果缓存到redis中，可以方便自定义更多元化的报告展现形式，提升了平台的扩展性（该功能不对外开源）。

更正说明：写这篇文章的时候，阿里云的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

性能测试光靠工具还不行，还需要有理论和实战技能的武装，请关注我的在线录播课《性能测试核心知识解惑》

说明

全链路压测主要是用在大促前夕的备战。用来模拟大促的全部链路，对整个链路进行压测，以检测平台在各个链路阶段中可能存在的不足。使备战更加精准和高效。

全链路压测平台通过应用系统改造使线上环境可以同时处理正常流量和测试流量，以支持线上不影响正常用户访问的集群读写压测，获得最真实的线上实际承载能力数据。要实现全链路压测，涉及的产品很多，包括网络、应用、中间件、数据库、安全、数据等都需要改造，涉及的应用范围很广，涵盖核心链路的上百个应用。

目标

从全链路压测链路模型的自动计算、全链路数据准备和流量发送的无缝衔接、应用容量的弹性伸缩、自动化的预案执行和验证等多个维度，使得整个大促备战更加高效和精准，将大促稳定性保障能力提升到一个崭新的高度。

工作内容

1.基础数据抽取

全链路压测的目的在于模拟双十一、618之类的大促，模拟的真实性尤为重要。基础数据（买卖、卖家、商品等）的构造是真实性保障的重要一环，为了模拟尽可能真实，全链路压测以线上数据为数据源，进行采样、过滤和脱敏，作为全链路压测的基础数据，数据量与线上数据保持同一个数量级，在数据库的sequence id上进行区间隔离。

2.链路与模型构造

全链路压测的链路代表要压测的业务范围，同一条链路需要构造海量的参数集合，代表不同用户的不同行为。链路范围、链路的访问量级、链路的参数集合、基础数据的特性一起构造了压测的业务模型。链路与模型的构造对压测结果的影响同样至关重要。

3.链路验证

在全链路压测平台的诞生阶段，链路验证耗费了压测项目组大量的时间和精力，电商业务具备复杂的业务特性，有上百条链路，每一条链路都需要确保能够让全链路压测引擎跑通，好在这是个一次性的工作，跑通以后出问题的概率不大，全链路压测平台也将链路验证功能集成到平台当中，能够自动化完成对压测链路的验证。

4.业务改造

全链路压测有不少地方需要在业务系统针对压测流量进行相应改造。比如压测链路的重复执行：全链路压测通常会进行好几个小时，这一特性要求链路能够被重复执行。实际情况当中，我们有不少链路并非是幂等的，需要针对存在这一特性的链路做专门的压测流量改造。再比如下游写流量的拦截、防止污染BI报表和线上推荐算法等场景都需要在业务系统进行相应改造。类似这样的改造点，在全链路压测早期时代非常多。

5.数据平台

数据平台是全链路压测的数据基地。由数据的准备、链路的构造、模型的构造等一系列重要模块构成，随着全链路压测的不断演进，数据平台沉淀了一系列自动化和智能化的基础设施，大幅提升全链路压测数据准备的效率和模型精确性。

6.流量平台

流量平台是全链路压测的计算中心，主要由两大部件构成：

·全链路压测操控中心，进行压测的配置和操控、数据的监控以及对压测引擎集群的管控。

·压测引擎，由控制台统一管控，部署在外网CDN集群，进行登录、会话同步，发送各种协议的压测请求、状态统计。

7.影子表

数据的隔离是全链路压测诞生阶段的一大难题。全链路压测的链路有读有写，并且在线上进行，为了不污染到线上的正常数据，全链路压测在同一个数据库的实例上对数据库表建同样结构的影子表来进行数据的隔离。

8.中间件改造

全链路压测的流量通过在链路上带上特定的压测参数进行区分，如果缺乏相应中间件的支持，在调用到下游系统的时候，压测标志就丢失了。因此需要所有中间件的协议都支持对压测流量的识别，使得压测标识能够随着调用传递下去，使得下游的应用、基础中间件和存储都能够识别压测流量。

9.安全机制

全链路压测的安全机制分两层：第一层是安全的监控和保护，建立非法流量的监控机制，正常用户访问不了测试数据，测试账户也访问不了正常数据，防止数据错乱；并且设置压测引擎集群的白名单，防止恶意访问；第二层是对压测流量的安全过滤，针对压测流量放松安全策略，使得压测流量不被判别为攻击流量。

 全链路压测平台的建设比这里说的事项要多的多，这里只是简单介绍了其中一些常见的工作事项。中间可能根据公司业务的不同，中间可能还有一些需要处理的比较复杂的事项。具体的内容要根据具体的事项去进行分析。这只是一个常规性的参考。

如果您有更好的想法或方案，欢迎您留言大家一起探讨。

 

做压测平台，可以参考BlazeMeter公司的界面及设计 
 
 

 
https://a.blazemeter.com/app/#/accounts/186768/workspaces/180481/dashboard

metersphere 搭建压测平台

sfa 的项目优化已经告一段落了 ，前两天协助测试的同学对sfa进行全量接口压测

现在的接口压测 是在本地上传脚本，到服务器执行脚本，下载jtl ，感觉很麻烦

我们现有的资源很难开发搭建自有的测试平台

之前的测试大佬推荐了 meterspheres

完美支持jmeter脚本
支持postmam脚本导入


metersphere 官网
metersphere docs 官网文档
基本使用


按照官方的quackstart 搭建服务


期间可能会有kafka连接错误 Kafka 不可用，请检查配置


msctl status 可以看到搭建成功


       Name                     Command                State                          Ports
-----------------------------------------------------------------------------------------------------------------
kafka                /opt/bitnami/scripts/kafka ...   Up         0.0.0.0:19092->19092/tcp, 0.0.0.0:9092->9092/tcp
ms-data-streaming    /deployments/run-java.sh         Up         0.0.0.0:8084->8084/tcp, 0.0.0.0:8085->8085/tcp
ms-node-controller   /deployments/run-java.sh         Exit 255   0.0.0.0:8082->8082/tcp
ms-server            /deployments/run-java.sh         Exit 255   0.0.0.0:8081->8081/tcp
mysql                docker-entrypoint.sh mysqld      Exit 255   0.0.0.0:3307->3306/tcp, 33060/tcp
zookeeper            /opt/bitnami/scripts/zooke ...   Exit 255   2181/tcp, 2888/tcp, 3888/tcp, 8080/tcp


新建接口测试

按照官方的样例就可以，



导入postman接口测

性能测试


性能测试这里有个小坑,找不到jmx 文件 The file /test/.jmx doesn’t exist or can’t be opened


感谢 王振老师的帮助


新建性能测试


上传 jmeter脚本 cvs




保存并执行


获取结果





本地测试 所以线程数比较少，时间也比较短


如果大规模压测的话 需要多个jmeter资源，没试过
希望可以有 jmeter docker集群部署教程，感谢

metersphere 刚开源没多久，存在这样那样的小问题，现阶段是我们公司最好的选择

与我们现有测试技术栈比较契合。上手很快
感谢 metersphere 团队，祝越来越好，加油
本文参考

如何做好性能压测（一）| 压测环境的设计和搭建
性能压测工具选型对比