思考！思考！jmeter线程数≠用户并发数

最近又在搞性能测试了，相较于之前的写脚本出数据就完事，这次深入的思考了一下测试出来的指标，到底有什么意义？？？

绞尽脑汁思考了好几天，终于有了点思路，写出来与大家分享，有不对的地方也希望大家能指出；

此处我们只探讨“单交易并发测试”这一个测试场景，本次单交易并发测试共测试了7个接口，我们下面拿一个接口为例来说：

1、首先，通过jmeter阶梯加压，我们发现jmeter线程数到50的时候，响应时间在可接受范围，TPS已经不再明显增加；

2、于是jmeter线程数给到50，持续加压5分钟，得到如下结果：

响应时间OK，TPS达到405.4/sec也OK（OK与否要与前期制定的性能方案做对比）

此时对比了TPS以后，达标了，就想着要测试下一个接口啦；但是：

一同事认为只关注TPS，达标了就可以了；

另一同事认为从用户使用角度，我们还要关注用户并发数，这个并发数反映了用户给系统的压力；现在我们得到了最大TPS，但是并发数还没有加到最大啊，应该继续加压找到最大的并发数！

这个时候感觉同事的话有道理又没道理，于是拿出了那个经典的图思考了半天（没错，就是下面这张图）：

随着并发压力的增加，前期响应时间较小，TPS持续上升，达到第一个拐点（此处认为就是我们上面测试的50），TPS达到了最大；

再持续加压，响应时间会增加，TPS也不会上升，一直到第二个拐点（感觉上像是同事想要压到的最大并发点），响应时间达到能接受的最大，TPS也能维持不下降；

思考了半天，觉得也应该继续压，找到系统的这个瓶颈，但是没考虑弄清楚压出来的数据有什么用，但是不管了，先压一版数据看看；

3、于是jmeter线程数给到了400，持续加压了5分钟，得到数据如下：

TPS到了498.0/sec，上升了一些

响应时间，看95%响应时间已经超了3S

4、头脑风暴

得到2组数据以后，我们看TPS都是达到要求的，但是这个50和400，怎么理解呢？

用户并发数50的时候系统性能最优，用户并发数400的时候系统性能达到瓶颈？？？

NO！！！TPS都能到400多，说明每秒可以处理400个请求，怎么可能用户并发数到400，系统就极限了呢！

--------------------------纠结中，网上搜索资料。。。

网上搜索了一些资料后，发现陷入了一个误区，即：我思考时，默认了这个jmeter线程数就是模拟了用户并发数，但是！不是这样的！！！

我们回去看，线程数为50时得到的结果，会发现其中有一个样本数121821，之前都忽略了这个值，现在我们分析：

1、线程数给了50，这里是工具给我们起了50个线程；

2、如果并发数是50,1S发送50个请求，那么5分钟时间，应该是发送了50*60*5=15000个请求；

3、但是跑了5分钟以后，我们发现样本为121821，远远超过了15000，就是在5分钟的时间内，给服务器发送了121821个请求；

4、那么121821/(5*60)=406，就是1S中发送了406个请求啊，就是用户并发数406啊，根本就不是50~

同理，149810/(5*60)=499

5、然后，我们发现：406    499  ，这不就是TPS吗！所以，我们关注用户并发数，到最后也就是这个TPS啊==

所以，我们是不是可以理解：

用户并发数406的时候，系统的性能是最优的，用户得到的响应也很快？？

用户并发数499的时候，系统的性能达到了瓶颈，达到了用户能接受的响应时间极限？？

嗯，应该是这样吧。。。