首先要明白一个误区，并发用户数和 jmeter 的线程数，它们是不对等的。并发用户数应该和 tps 是一个概念，假如需求是想获取 1000 个用户同时操作时，系统能否承受得住或者系统各项指标反应如何，我们应该拿 tps 来给出答案。jmeter 的线程数大小仅仅是一个压力的大小概念。
所以说我们在接口压测时，肯定是要采用递增并发时的策略来获取系统最大的 tps。至于递增间隔需要参考基准测试时，接口的响应时间。如果响应时间很小，那你增加步数就小一点，如果响应时间大，步数就需要大一点。

除了楼上的办法，当数据量很大时可以把数据写入 redis，通过插件获取参数化数据

是呀，也不知道天天干嘛呢？

Sampler 里填的截图出来看看。只让看现象，无法看到原因

我认为第一次实验结论第三点完全没有必要。并发线程数只是压力工具用来施压的一个策略，不能用来衡量系统支持的并发能力。tps 才是可以真正可以反应系统支持的并发能力。还有就是群主不要把 rps 以及 tps 做为两个概念，其实他们按理说是一致的没有区别，都是反应服务器在一段时间可以处理的多少事物。并且你分析的拐点我也不太认可，你第一次 10 秒内 rps 增加到 100，tps 也是在 10s 增加到了 100，但第二次是在 20 秒内直接增加到了 400，但是你看 20 秒的 tps 确实在连 300 都不到。这个时候性能已经开始衰减了吧。

数据库连接会不会没有断开呢？导致一直 20 20 的递增

高大上，通篇读下来，就觉得牛逼。然后就没有然后了

哦哦，明白了。谢谢解惑了

为什么 3600×20% 之后还要×8 呢？

你这直接写个脚本，调用你们的业务接口造数据不可以吗？要不要自动化框架无所谓吧。