基于 Jmeter 的轻量级云压测平台的原理与实现 ：压测引擎

目录

前言：

平台的技术

平台的初衷

平台从开源开始到现在拥有了一些核心的功能：

印象深刻的技术点：

为什么执着于 Jmeter-API

平台能带来什么

压测引擎

前端入口

Controller

必要的 Jmeter 配置准备

对 Jmeter 脚本的必要加载操作

单机执行脚本

分布式执行脚本

最后

---

前言：

JMeter 是一个广泛使用的性能测试工具，它支持许多不同的测试技术和方法。其中，云压测是一种常用的测试方法，它可以使用云计算资源来实现大规模的测试和压力测试。 

平台的技术

平台的初衷

平台的核心初衷很简单，就是能在浏览器中完成一系列 Jmeter 操作，包括启停脚本，在线监控，在线报告。
但是想一下，其实 Jmeter 的核心初衷貌似更简单：“load test functional behavior and measure performance”，大意是能进行性能测试并且查看监控结果。
结果 Jmeter 的代码量突破了 67 万行。
平台中我的代码突破了 8000 行。
稍微感慨啊，我本来合计 “小而美” 搞定的，看来初衷和代码行数真的不成正比。

平台从开源开始到现在拥有了一些核心的功能：

• 启动脚本，包括 Jmeter-API 的启动和调用 Jmeter-Home 的拼装脚本启动，包括单机节点启动和分布式启动。
• 全部停止脚本和单独停止脚本，单机和分布式情况下都适用。
• 支持平台内适用 Jmeter-API 的方式同时启动多脚本，同时监控的数据是正确的。
• Jmeter-API 启动脚本时，支持 Jmeter 自带的函数，同时支持更多的 Jmeter 的常用 sampler。
• 支持 Jmeter-API 方式的脚本调试，在线也能看脚本的效果和问题。
• 参数化文件支持自动同步到各个节点机。
• 性能/调试报告的异步生成及下载。
• 系统空间的控制，支持不生成测试报告和保留报告而仅删除测试结果数据。

印象深刻的技术点：

• shiro 的配置及权限控制。
• spring-boot 读取配置文件及 Controller——Service——DAO——Mapper 的各种操作。
• 子类的方式重写 Jmeter 的源码方法。
• javassist 字节码修改方式重写 Jmeter 源码。
• 观察者模式重写 Jmeter 调用脚本的各种监听器。
• classLoader 的实际运用和 static 代码块。
• Java 内调用命令行和各种回调。
• 异步线程池方式实现 xsl 模板生成 html 报告。
• 文件上传下载。
• 前端监控的定时触发，数据在内存中如何对压测机性能影响最小，内存和数据库。
• 前端监控的数据如何计算得到，尤其是分布式这些数据要怎么处理。
• Echarts 的写法和调试。
• 数据库表的设计，配置项的设计。

然后我发现自己面对所有这些技术问题，解决的速度是很快的，我觉得自己是战无不胜的。

issue 中提的一个问题我印象很深刻，是说为什么我的平台执行不了 Jmeter 自带函数？
为此我打了几十个断点来追查问题，最终确认了是动态的系统变量少了东西。
印象深刻一是因为源码查的真的很深入，看过源码的会了解，Jmeter 对 jmx 树的解析相当复杂，能有几十个各种实现类，断点很不好打。二是我真的一度放弃过，当然最终坚持下来并很快解决了。

然后可惜，代码还是来到了 8000 行，我的 “小而美” 去哪里了。

为什么执着于 Jmeter-API

就一压测任务，你直接调用 Jmeter 脚本执行就好了啊，也有测试报告查看，也支持分布式压