文章转发，原文来自：https://cloud.tencent.com/developer/article/1784548?ivk_sa=1024320u
【概念解释】
并发线程数：指的是施压机施加的同时请求的线程数量。比如，我启动并发线程数100，即我会在施压机器上面启动100个线程，不断地向服务器发请求。
QPS：每秒请求数，即在不断向服务器发送请求的情况下，服务器每秒能够处理的请求数量。
平均耗时：平均每个请求的耗时。即所有线程所有请求的总耗时➗总请求数。平均耗时反映的是接口处理请求的时间，往往跟被测服务器的繁忙程度和资源有关。
95分位耗时：相对于平均耗时，95分位耗时更多地被用于反映接口性能的方面。因为95分位耗时能够去除一些最大值毛刺对整体数据的影响。更加能够反馈出接口真实的体验。
在Jmeter的Grafana界面，上述几个数据分别对应到图片里面的这几个地方。
【QPS与平均耗时的数据关系】
既然QPS反映的是每秒处理请求数，而平均耗时又是平均每个请求的耗时，我们自然地会想，是不是有这么一个公式可以把上面的几个数据概念联系在一起呢？比如，平均耗时的倒数，就是一秒钟能够处理的请求数，再乘以并发线程数是不是就是QPS呢？是不是就有下面的公式呢？
QPS = 并发线程数 * ( 1000 / 平均耗时ms )
为了说明上面的公式，在理想状态下，我做了一个这样的假设，假设施压机的并发线程数是2个，但两个并发线程的遭遇非常不一样，线程1发出的请求每1.5秒才处理完，而线程2发出的请求每0.5秒就处理完了。在这种情况下一分钟内，线程1能够处理40个请求，线程2能够处理120个请求。所以施压机得到的一分钟处理总请求数为160个，QPS为2.6。而这一分钟里面接口平均耗时则为0.75秒（120秒 / 160个请求）。平均耗时的倒数 * 2刚好等于2.6 。
理想状态下QPS = 并发线程数 * （1000 / 平均耗时ms）是成立的
但如果我们把Jmeter压测跑起来，我们看到实际的数据，就会发现不符合上面的公式：
并发线程数 2 * ( 1000 / 平均耗时 0.68ms ) = 2941
很显然：QPS 2390 ≠ 2941
可以通过上面的例子看出，QPS是不等于平均耗时的倒数乘以并发线程数的。那问题出在哪里呢？是不是Jmeter数据统计出问题，或者说这里有其他的问题所在呢？
减少写数据的步骤能够明显增加QPS
经过研究发现，通过简单的去除一些存数据的操作，能够在平均耗时不增加的情况下，增加QPS值。说明，其实每个线程不是单纯地在发送请求，在发送请求前后，还存在处理请求数据，转存数据到master等操作。所以实际上施压机的时间分片是这样的：
实际情况下Jmeter会有诸如处理数据一类的额外时间消耗
由于数据处理等时间上的消耗，线程实际上并不是一个请求发完立马发下一个请求的。所以通过耗时与线程数并不能直接推导出QPS。
那么问题来了，Jmeter本身的时间消耗会不会影响最终的结果，影响对服务器的性能评价和判断呢？
只要并发线程足够多，就可以把被测对象的压力值打满，从而测出被测对象的最大QPS，是不会对最终测试造成影响的。比如，被测服务服务1000个线程可以到达CPU瓶颈，施压机使用1000并发线程数，可能会存在一些Jmeter本身的消耗而达不到被测服务的最大QPS值，但是只要继续增大并发线程，比如增加到1200~1500并发即可把本身的消耗填平，把被测服务的QPS打满。
【总结】
通过上面的推导和论证，由于Jmeter自身写数据等的需要，我们知道在Jmeter压测里面QPS、并发线程数和平均耗时是没有一个严格的相乘的关系，而是一个在一定范围内呈正相关的关系。即在服务器到达极限之前（到达极限QPS之前），并发线程数越大，QPS也会增大，平均耗时也会一定增加。我们应该认识到在使用Jmeter的前提下，我们应该最终以QPS和平均耗时为评判被测对象的最终结果（并发线程数作为施加的压力量而不作为评判被测对象处理同步线程的数值）。