不错不错~~~

嗯嗯... 仅仅给是楼主提下建议... 主要是要测试 RPC 的需求的话,必须要将 RPC 接口本身的包引入 JMETER 环境...

楼主,经我验证,你的平台目前需要改掉 3 个地方才能进行 RPC 脚本的测试;
StressTestFileServiceImpl.java 中修改三处:

// 1. 加入 loader 声明的全局变量

private static final DynamicClassLoader loader;

// 2. static 代码块的最后 加入
loader = AccessController.doPrivileged(
new java.security.PrivilegedAction() {
@Override
public DynamicClassLoader run() {
return new DynamicClassLoader(jars.toArray(new URL[jars.size()]));
}
}
);
// 3. setJmeterProperties() 方法开始加入
Thread.currentThread().setContextClassLoader(loader);

以上均经过实测.

不过如果想使用一套 jmeter 环境的话,可以考虑下面的解决方案;

1. 自定义一个 jmeter.properties, 修改 search_paths 属性,指向某个测试任务专用的路径,可以和参数化文件放在一起;
2. 启动 jmeter 时,使用-p 参数,用法:-p, --propfile the jmeter property file to use 这样可以防止测试 jar 污染 jmeter 环境

不是的... 使用 jmeter 测试 RPC 需求的时候,需要把测试 jar 和依赖的 jar 放到 JmeterHome\lib\ext 下面,可以预见经历若干个测试需求以后,JmeterHome\lib\ext 下会有大量重复的 jar... 引发 jar 包冲突...

嗯. 内嵌调用 API 的方式 确实在 RPC 测试方面有天然的劣势... 这样会导致多个测试需求共用 JRE

1. 可能因需要刷新 JRE 导致的不定时重启...
2. 多个需求会频繁上传 jar,带来 jar 冲突之类的问题... 哎... 难...

嗯. 不生成结果这个思路可以的... 有趋势图和统计之后的数据一般都足够了..
但是楼主这个好像没有那种汇总的数据... 就是 对整个测试做一个采样分析的比如 总平均 TPS,TP99,MAX,MIN 之类的...
另外就是一个最大的问题就是,很多公司都有诸如 dubbo、SAF 之类的 SOA 系统，测试这种类型的需求，需要：引入被测的 jar--->调用被测方法--->测试并统计结果...
楼主这种直接 CALL API 的方式,如果有多人同时使用并测试 SOA 的话,怎么搞呢?

楼主,M-S 模式和多 M 模式各有优劣吧...我觉得 M-S 模式还有个问题就是较大 TPS,如你所说的 8W,跑稳定性测试的时候,比如跑 2 个小时,会产生巨大无比的 JTL 文件... 这个文件处理和分析都是噩梦... 而我的多 M 模式,则结果数据分散在多个 M 上,目前我是使用自己写的算法将 JTL--->JSON,将 JTL 里每 S 的数据聚合成 JSON 数组的一条,大概的数据结构就是: 2018102601<---> PASS:100,FAILED:10,AVG:10MS,TP99:15 ...,一个数十 G 的 JTL 产生的 JSON 文件一般都不超过 1MB,然后将各个 M 的 JSON 数据合并.
目前我的难点是实时的展示测试数据...

替您回复下,Jmeter 是支持的...

嗯..用了...也拜读了你的代码... 确实很清晰易懂... 但是有个建议反馈给楼主:
jmeter master 和 slave 之间用的 RMI 协议进行通讯的,网络开销很大..在进行超大 TPS 压测时,master 的网卡时常会成为瓶颈.及时不成为瓶颈,经过在压测中数次验证, Master*1 Slave*3 架构可以发出的压力一般都是小于 Master *4 的... 在实战中,我都是使用多个 Master 的模式压测的... Master-Slave 的基本不用