支持

感谢对我发言的肯定。

最近在面试，也在探索这方面的知识。补充一些这里没有的吧，个人浅见。

1. 面试问题要搞清楚，面试节奏要紧促一些，别面试官思考时间太长，到时间了问不了几个方面的问题，不全面。
2. 岗位述求要搞清楚，也就是岗位要求技能的权重要搞清楚，权重低的问题少一些，权重高的问题多一些。
3. 不要太考虑这个人的性价比，比如水平超过要的钱很多，但是要的特别少的那种，不要过多考虑，不是说省钱都不要，而是岗位的匹配是第一位的。
4. 及时送走不符合的候选人，不要浪费其他面试官的时间（扎心抱歉）。
5. 如果招的是自己组内的人，自己要带的人，那么无论自己是几面，都是第一责任人，就是说这个人的决定权必然在自己手里，候选人的去留自己一定要有数，不能说自己没看上，希望别人再帮忙鉴定一下，帮自己看一下。自己组内的人必须自己决定，别人的眼光只是辅助。
6. 越后面的面试官越责任越重，当然这个在公司内可能说法很多，比如领导面说过了，然后你说不过可能不太好。但是宗旨是相同的，越后面的面试官责任越重，越后面的面试官越要有自己独到的见解，独到的考察点。
7. 几轮面试应该有侧重，就比如 HR 面的是挑战 + 证实一样，我理解是一面全面基础，二面细化，三面行业/岗位格局。当然各个公司情况不同，可能一面就全问了也没啥（时间要控制）。
8. 面试不代表一切，也是看缘分，我挂掉过很多人，也并不是完全客观，也不是说她/他来了肯定不行。我一直在检讨。信任需要建立，互相信任是合作的基础。

是有这个类的。

可以尝试生成一个比较稳定的自动化脚本模板。未来的迭代都是向这个模板添加特定的需求。可以生成一批不同接口的 jmx 文件，让其成为素材，每次添加即可。当然这需要双开或者多开 Jmeter 来编辑。
建议每一个迭代都要保存好 jmx 文件，这样面对新的迭代可以参考历史文件，让工作量降低。
同时要写好每一个请求的注释，要能真正区分 sampler 的作用和特点。
Jmeter 是有一些缺点无法避免的，比如是一个本地工具无法和线上文档匹配，本身是脚本文件本地保存查找等，麻烦是必然的。需要结合其它工具来使用。

正常 JVM 环境中是有这个类的。你用的 Jmeter 是 5.1.1 吗。

可以 debug 一下看看问题在哪里。详细的可以提一个 issue。

插件需要加载平台的 JVM 环境中。这个需要自己手动加载，如在 IDE 中引用三方 jar 包，pom 文件制定插件所在的目录等。

5.1.1 目前支持的不好，我都是用的 4.0 的。

插件自己加到环境里。

赞，做的还是不错的。

“每个线程组线程数的比例，jmeter 原生本身会做控制，这个并不需要平台介入吧”，据我了解，Jmeter 本身控制不了比例，能控制的仅是数量。平台需要根据比例计算出数量，传给 Jmeter 让其执行。
这种解决办法也有吧，一个线程组一个脚本，多个脚本同时执行达到多个线程组同时进行的效果，这也是可以的，可以避开问题，曲线救国吧。

目前没做这么细。
每个 slave 执行的是相同的脚本，像线程数，步长等等都是一样的，本身 Jmeter 并没有 master 配置一个总的线程数，其他 slave 去平分这些线程数的概念（或者权重平分），都是 master 打算要执行一个脚本，其他 slave 都是按照这个来执行，这是两种压力设计，很明显你说的这种 Jmeter 本身就没有。
你说的这种其实要考虑的很多，比如一个脚本内配置了多个线程组，每个线程组的线程数都不一样，那你说的 “直到达到指定线程数量” 要做的就比较多了，比如要保持住每个线程组线程数的比例，要同步增加，或者说 “指定线程数量” 要细分化，即对每一个线程数都要有一个指定的线程数量，这样如果几个线程组还行，如果千百个线程组，你这要如何细分。这就是举个例子吧，意思是说实际要做的没有那么简单。
Jmeter 这种压力设计是有它的考虑的，我也认为是最省事的。
平台目前不想颠覆 Jmeter 的理念，平台的核心目前还是保持住 Jmeter 的所有特性，是保持，不是另立门户。

你好，感谢对平台的肯定。
定时任务这块如果是要结合 web 平台来做，肯定是需要代码量的，这部分我还没开发。如果是基于 Jmeter 的，那么使用 Jmeter-Home 应该是可以的（这你也试过了可以，感谢），因为使用 Jmeter-Home 的原理就是执行 Jmx 脚本，和使用源生 Jmeter 是一样一样的。

放弃 Jmeter5 是因为我当初在测试的时候，发现 Jmeter 5 对参数化文件支持的不好，具体我也忘记了，我们就是普通的使用回车换行的参数化文件，但那天是遇到了问题一直报请求失败，当时还没有调试脚本的功能，追查了很久发现回退 Jmeter 版本就没问题了，所以就一直保留 Jmeter4 的 api 方式，一直不升级。

以上是对你问题的一些回答吧，下面我扯点儿别的。

1. 定时任务为啥一直不做呢，因为我觉得定时任务总有一些弊端和不太实用的。 性能测试是一个严肃的事情，说每时每刻都需要人盯着都不为过，那么有了定时任务让其自动执行是不太安全的。可能你会说轻量级的相当于回归测试的压测需要定时执行，来检查系统的健康程度，我仍然认为这不是不盯着让它自动运行的理由，不够严肃，一旦出了问题得不偿失（比如各种脏数据问题内存的数据库的，给流量高峰添乱等等）。 说不太实用是因为除了定时任务，更需要的往往是钩子执行，如代码提交之后就进行性能测试，这样更有意义一些，就是说不仅仅时间是触发条件，其他操作也要成为性能测试的触发条件，结合起来才是最实用的。而这种开发量稍微大了些，稍微偏离了性能测试平台的主核心任务，这个需要集成更多的三方包来搞，或者说业内对这里已经有方案如 Jenkins+Jmeter 还是可以的。 同时 Jmeter 自己也有对定时任务的实现，简单的定时任务完全可以胜任，所以平台对这部分需求也不急迫。
2. Jmeter 4 已经满足了我现在的所有需求，所以我是觉得没必要赶潮流硬上 Jmeter 5，所以我也不升级。未来如果有场景非 Jmeter 5 不可，那我肯定会升级的。

这个功能已经废弃。后续都删掉。

云服务器和本地服务器很类似吧。建议你本地搭完环境之后和你们运维合作，搭建阿里云服务器。
因为涉及服务器的开销价钱，用户权限，端口权限，磁盘文件大小等等。

虎躯一震。

1. 找到工作，现在能找工作换工作的都是实力的体现，牛人。
2. 去深造找个避风港，本或者本和硕一起都可以，博可以考虑出国读。出来都是不同的世界。
3. 别轻易换行业。计算机还能有十年衰退期，未来是稳定期。

代码 review 主观性很强，一人一个看法很正常。
所以这就需要有一个拿结论的人，一般是经理甚至总监，一个人就够了。

review 主要是看代码规范，如魔鬼数字，注释，过长的方法，公共方法的抽取，定义公共变量，是否按要求提示，异常的捕获，父类子类继承覆盖等等。其次还要看关键算法，举例比如是向后循环还是向前循环更优，用什么数据结构更好，是不是用多线程异步执行等等。还要看对系统的影响，比如内存占用是不是合理，内存回收策略，CPU 会不会高占用，对 GC 的影响等等。还要看架构的使用，比如查询比较这种可以直接使用数据库查询出来而不能程序遍历比较，常驻内存数据可以放到外部存储，异步队列执行，异常重启数据的恢复等等。
要举例的太多太多，往往你说的否定我写的，我否定你写的这类都是在代码规范上较劲儿，看着还是比较低端的。相信成熟的 review 中，整个 team 都会沉浸在技术的最优解上，劲儿往一处使，都会有收获。

但是这种 review 也有几个弊端，一是容易看出来一个人的水平高低，这对领导往往是致命的。二是比较费时间，节奏不好很容易开成大会浪费生命无意义。所以没有 review 我表示理解。
对于测试来说，review 都是开发自己的事情，我比较无所谓。

高 CPU 消耗是说 slave 负载机的瓶颈一般是 CPU，或者网络带宽。
master 可以是 Jmeter_HOME 也可以是 服务器进程，两者可以选择，可以配置。
我的平台主要是让 Jmeter 的单机或者分布式更方便使用，目前并不会提高性能。

Jmeter 无论单机还是 slave 就是一个 Java 进程，按照调优 JVM 的方式调优就好了。

没影响。
负载机是高 CPU 消耗的应用，除非机器 CPU 核心特别多如 32 核及以上，可以使用多进程，像你的 8C16G 的单进程就可以了，是没必要搞单 IP 多端口的多个 slave 进程的。
当然你们可以多尝试尝试。

查看结果树应该没问题，主要是另外两个监听属于插件，删掉就可以了。
平台自带监听，比 jp@gc 的监听要和谐一些（自认为功能也好了不少 ）。

很燃，很棒。

作者说的很清楚，如果要用 locust 做高压力测试就堆硬件，毕竟硬件比人工便宜。如果硬件资源有限制，则推荐 Jmeter。

如果你在一个领域上没有做到出类拔萃，想换一个领域做到出类拔萃，这是很难让人相信的。
失败了再爬起来，在职场是非常非常非常难的，职业生涯建议还是滚雪球，雪球大了再换方向。
还有，你这是跳城市，比跳槽风险高多多了，基本跳城市的都要从头再来。
你这在跳城市中属于正常现象，希望你的信心还要保持，别灰心，要坚持。