基于 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 行，我的 “小而美” 去哪里了。