你说的有道理。不过我还没写网页版的性能测试平台呢，这里仅是在看 Locust。
@debugtalk 他阿里同事实现了 GO 语言的 Locust 客户端 boomer，我未来还会继续分析 GO 语言的可行性的。boomer 的源码我也在学习。

我写的是 Locust 的你竟然来问我 Jmeter 的问题……让我一阵心酸啊。
我开始以为你问的是 Threads(users) 的数量，后来仔细看了一下，是问的 sampler 即用例中的请求数。
最终能设置多少个 sampler 确实是依赖内存的消耗的，这里解释一下。
Jmeter 编辑用例增加 sampler 的时候，用例是会保存成 jmx 用例文件的，jmx 用例文件中即包含了每个 sampler 的信息。
而 Jmeter 性能测试时，会将正常状态（没有灰化隐藏）的 sampler 信息（很多个）加载到本身的内存中，确切说是 JVM 的 Heap 中，用来当做原始测试数据。
那么这会遇到第一个内存障碍，如果你的有效的 jmx 用例文件就 100MB，Jmeter 的内存 Heap 才设置了 50MB，那这个用例可能是加载不起来的。
性能测试时，由于不能污染原始的内存中的 jmx 文件，比如做参数化等细节，每一个 jmx 会被复制出去，由于具体 Jmeter 是使用线程来实现压力机制的，所以复制的 jmx 文件会到线程的内存中，这次是在 JVM 的永久代中，而每个线程的内存可以使用-Xss 参数配置。
那么这回遇到第二个内存障碍，如果 jmx 有效的比较大，而-Xss 设置的比较小，那么性能测试时也是有可能失败的。
注意：
1.Jmeter 加载/运行 用例/sampler 时，如果遇到问题，都会抛出 JVM 级别的异常的，肯定是会打到日志上的，这部分定位问题十分简单，而解决也比较简单，增加内存就好了。
2.真正的用例在内存中不会像 jmx 文件那么大的，Jmeter 会提炼用例数据的，内存占用会比文件占用的空间小得多。（具体提炼多少需要看源码，这里无法尽述）。
总结：
sampler 多少确实是内存决定的，内存够大就没事，有问题就看日志，注意调整-Xms -Xmx -Xss 参数。

1.你到底什么理解，我到底什么误解，你说出来，想喷我就勇敢点儿。
2.“locust 更新的少可能是因为没有太多高并发场景能达到 locust 应用级别，jmeter 就足够了”。这句暴露了你的实力。我可以这么讲，Jmeter3.3 目前的功能，甩开 locust 太远，基本就没有 locust 什么事情了。locust 的作者是有自知自明，不更新很明智。

你直接用 Jmeter 就都有这些功能了。

号前段时间丢了，导致一直挖坟……
楼主是很有激情的，一直在不断解决问题的路上，看你搞 docker，服务器监控，那就是把运维的活也干了。
测试开发的工作还是比较杂的，我的观点还是测开做的都是开发没时间搞的事情，比如应该自测阶段完成的用例，比如整个流程的串通，然后测开闲下来的时候还要做各种工具，把开发没时间搞的事情做的更高效。
那么测试面对的，比开发接触的要广的多很多，同样工龄的开发和测试，接触的肯定不一样，不同的语言，比开发多得多的工具，运维工作，很多开发集合起来的业务，还有你说的 bug 平台，各种用例平台，性能测试平台，云平台等等。
工作就是这样，楼主也一直在这条路上有激情的奔跑着，很棒。
如果说技术的 x 轴是广度，y 轴是深度，那么测试偏向于 x 轴，开发偏向于 y 轴。(x,y) 的值是你的技术能力。
在此我就是希望楼主多关注一些深度的东西吧。
2 年就到管理层，甚至让手下面试你，各种嘲讽，至少说明，这个团队的能力真的太弱了，你说的，如果每一个人专注不同的业务，不同的技术，那么问住你是分分钟的事情，这说明，或者他们没有你深入，或者他们就没深入，或者你们就没啥值得骄傲的东西。你们团队每个人的特点很弱，也就是说，人员太弱，没有技术深度。
当然你都跳出来了，希望楼主能感受到更大的挑战。
从楼主的字里行间也看出来了，想做创业者，也就是要带领一些人，这没啥不好，不是说非得技术如何如何才有资格带人，这是错的，带人也是要一步一步学的，这没什么。
我只是想说，希望楼主在热心于技术的广度，带人的热情，也不要忘了技术的深度，多看一些底层的东西。
底层的东西并非多么难，你有代码基础，再看一些比如 CPU，磁盘，计算机原理，各种协议原理，简单算法，linux，数据库原理，缓存原理，数据结构，应该就差不多了。
楼主的经理也在激励着我，共勉。

我还以为你弃用 Jmeter 是业务不对头呢……对接口测试，现阶段的 Jmeter 比 httprunner 好多了。你还来了一句操作不方便……别误导别人了好不好。说些肯定能遇到的：httprunner 面对循环重复请求要怎么做？断言的正则表达式怎么做？出了问题怎么 debug？怎么搞定时器？不是 http(s) 协议怎么办？遇到需要校验数据库/缓存变动，只需要一个简单的 SQL，并不是 http 请求怎么弄？怎么实时看到访问结果，如果有 1000 个请求前 2 个就失败了而不需要执行后面的 998 个以免脏数据 httprunner 要怎么做？
这些问题你要打开 IDE，自己造轮子了？
我都不用说 locust 的测试性能有硬伤，协程 + 脚本语言性能的硬伤，上面这些你都搞不定，要二次开发。
别简单一句这些更好，你到底做没做过接口测试，我都怀疑。
如果是你业务不符合，就说业务的问题，别扯工具能力。

呵呵了，我能发现这个 bug 你就庆幸吧，要不然上线出了问题，你更惨，除了加班纠正，如果有错误数据更完（内存 bug 等更是致命伤）。
我才赚多少钱，我可不陪你加班。
这种 bug 就是你自己都没验过功能，你要是嫌不好改发邮件，抄送你们项目经理，抄送我老大。

楼主这套框架很值得学习借鉴，好东西。
测试数据的痛点，docker 的学习，楼主加油。

正好我也有需求要做 Jmeter+ant+Jenkins 的自动化接口测试。
不同的是我的用例信息保存在数据库里，数据来源不同，搞了一天。

楼主最主要的细节没写：获取测试数据对应行。
我的做法是：获取 count 循环数量的同时，获取数据的 ID 主键集合，用逗号分隔保存在一个变量里。
获取测试数据对应行时，同时保存及设置用户变量 index，index 从 0 开始计数。
index 是 ID 主键集合的索引，由于已经根据逗号分隔过了，很容易取到。
再根据得到的 ID 主键来获取数据行，完成用户参数的初始化。

再说一下，其实报告的模板我没修改得像楼主这么麻烦，我就是把 beanshell samper 的名称改成了空格，自动就过滤掉了。

还有 if 逻辑控件，注意是 == 号。

有时间我也出一个 JDBC 的接口测试实践。

招聘还是更多的看这个人适不适合这个岗位吧，要多少钱，值不值这个钱，还有没有培养的潜力。说点儿不同的，这个 10 年 QA 都回答上来你的问题，那早就面试你了啊，人家入行早，肯学，还轮的着你面试他。再说，工具的使用怎么就没有价值了呢，你还来一句算法语法不用问，已经跨过这个 level 了。如果他跟你大侃特侃架构，可能就是读了几本架构的书，你就满意了？找到知己了？算法语法的不同，不说深扣有多少用，至少避免踩坑吧。
好了，你按照你的要求招到了跟你侃架构的人，那你能提供给他一个搞架构的环境么？你能满足这种人的薪资要求么？你文章中什么都没提，让我们怎么判断。
做事情是需要耐心的，楼主先入为主的思维比较严重，就觉得 10 年 QA 就应该怎么样怎么样，完全是个小年轻的思维啊。再说回来，人家 10 年工作经验，面对架构流程侃侃而谈，是面试你的好吧。你出发点是不是偏了啊？
再说，要难住一个人其实比较容易，人家也可以难住你。
对于新技术有接触，对于自己的工作有深入理解是好事情，我也并不是说这个 10 年的 QA 是合格的，楼主应该招他。我就是单纯的从招聘的角度。你如果觉得这个岗位对流程和技术前沿要求比较多，那筛选简历完全可以做到，没必要把人叫过来整一遍，刷一遍荣誉。