jmeter线程数与用户数、tps的认知误区

误区一：jmeter 线程数就是用户并发数

案例：

业务需求：要求tps达到500/s，1000并发数2秒完成处理

大部分的测试同学是这样压测的,将jmeter的线程数直接从200、300、400这样调试到tps出现拐点。如果400线程符合了，就说明支持400的用户数。
更有部分同学验证第二点的时候，直接压测1000个线程

误区:
1、正常的压测过程是，先压测出一个线程下的tps，然后根据以下的公式算出大概需要的jmeter线程数，以上的例子中，如果一个线程下的tps为10tps。那你的jmeter 线程数只需要50个线程就够了。完全不需要200以上，那是在浪费资源

线程数 = 业务tps / 单个线程tps

那我们怎么观察tps拐点呢。
用阶梯式压测：阶梯式压测可以很清晰的显示性能衰减过程，然后这个过程中你可能会看到很奇怪的现象，就是递增过程的抖动，如果这个抖动过大，就是有性能问题。
从上个公式拿到50个线程后，我们以这个为最高线程进行阶梯式压测。观察tps的走势图，如果tps走势不跟线程数呈递增状态，那就有瓶颈。当然并不是说100、200这样的压测不能测出最高tps，而是相比阶梯式压测不那么直观，且要尝试不少线程数场景。

2、jmeter 的虚拟用户数大小不能说明支持的用户数是多少，这里jmeter 的用户数只代表jmeter的压力大小而已，支持的用户数跟你的tps 以及用户的请求次数有关。比如这里的500tps。如果业务场景是一个用户只操作一次接口，那就说明是这个接口能支持500的用户数，这里指的是支持最小的用户数。如果这个接口，1万个用户数，只有1000个是同时操作，那就是这个接口的并发度只有十分之一，那这个接口的支持用户数就是，500tps/0.1 = 5000，也就是支持5000的用户数。

.支持最大并发用户数=TPS /并发度

3、那什么时候下，jmeter的线程数就是支持的用户数呢。需要满足两个点，第一，jmeter 脚本设置循环1次，第二，单接口。

误区二：jmeter 线程数不断增加

在真实压测过程中，我们会发现，当我们压测符合业务需求的时候，我们还会不断的去加压去压测。直接把服务器压到90%的cpu。很多人理解这样的场景是为了验证：如果用户超出了当前评估的用户数，系统会不会挂掉。
根据以下的公式（只代表是这种关系，不能完全等价该公式），你的tps不变的情况下，线程数不断增加，响应时间是肯定是增加的，以致完全超时，所以当你的报告发现大量的超时时，你可以考虑是不是线程数过大了。所以，压测到最优的tps后，就不需要压测了，哪怕最后你的线程数只需要100个线程。有些人很担忧，100个线程，这压力哪够呀，加到1000一步步试。最后压测下来，发现根本没啥区别，除了响应时间大了一点。那就是在浪费你的时间成本。当然这个100线程能体现最优的tps。

tps= 1000/响应时间 * 线程数

那我们怎么解决这个用户是否超量带来的系统问题呢。本质上是业务的需求，也就是说，我们首先怀疑的是，这个tps是否满足了用户数超量的情况。