jmeter支持分布式测试，在分布式模式下，由一台调度机调度所有的执行机（集群节点），执行脚本时可以自由的选择单节点执行或者分发集群中指定或全部的机器执行。在使用调度机客户端分发脚本时，无论是在GUI模式还是non-GUI模式，脚本日志的收集及报告的生成都无任何问题，但是如果是使用jmeter SDK在代码中调用客户端大并发分发脚本到执行机执行，则会存在日志无法实时获取的问题（超大jmx脚本执行时产生的超大日志通过网络传输需要时间）。
通过分析jmeter SDK的源代码，发现日志的收集是异步执行的，而在SDK中并未提供日志收集完成的通知能力，导致根据日志生成报告时经常出错（实际的脚本都是正常执行完的）。分析上述问题，提供的解决方案如下：
- 脚本执行完后，当前线程睡眠一定时间
- 暴力反射尝试获得日志的传输状态
- 修改jmeter SDK的源代码，在其中增加监听机制
- 当前线程只负责执行脚本到结束状态，定时收集日志并生成报告
针对以上的4种方案，分析其优缺点：
- 日志大小无法确定，睡眠时间无法确定，而且睡眠会导致线程等待，可能会产生ThreadInterruptException
- jmeter SDK注释写的很差（基本无注释），分析源代码需要强大的技术能力和一定的时间，目前的时间排期不允许
- 同样由于注释的原因，也需要强大的技术能力和一定的时间，不过难度比第二种方式要低，也是可以产生最优结果的解决方案
- 技术要求最低，实现容易，但是日志和报告的生成会延迟（基于定时器的周期）
在当前产品的需求上，其实日志和报告并不是极其敏感和实时性要求高的数据，所以最终选择第4种方案，代码如下：
每个十分钟拉取距今14400秒（任务执行超时时间，可配置启动参数）还未获取日志的任务并尝试获取日志。
因为是异步的拉取日志，所以在拉取日志之前加载一次jmeter的配置。
考虑到每一次停机维护的时间可能会很长（超过当前设置的任务超时时间），因此还需要提供一个启动应用时扫描任务的能力。
CommandLineRunner接口标识应用启动完成时执行该接口的实现类，因此需要使用@Component将类的对象加入到IOC容器中。
日志拉取完成后，再处理报告，同样的原理每个十分钟拉取距今14400秒（任务执行超时时间，可配置启动参数）还未获取日志的任务并尝试根据日志生成报告。
同样因为是异步生成报告，因此需要在生成报告时，加载一次jmeter的配置管理。此处也要考虑停机维护的问题，使用CommandLineRunner。
到此，jmeter日志和执行生成的问题完美解决，每一次执行完的任务可能会有10左右的延迟时间用来获取日志和报告。
其他文章回顾
嘉为科技：企业应用运维自动化应该如何设计？zhuanlan.zhihu.com
扫一扫
577
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
