我们在压测工具制作中，一直存在一个争议——吞吐量的计算。
在性能测试中，吞吐量的计算有两种常见的公式：
公式1： 吞吐量=并发数/平均响应时间
公式2： 吞吐量=请求总数/总时长
公式1、2大家应该都接触过，虽然看上去不一样，其实理论上都是ok的。首先我们可以从C = nL / T 推导：
并发=请求总数*平均响应时间 / 总时长
=》并发 / 平均响应时间 = 请求总数 / 总时长
=》公式1 = 公式2
然后我们构建三组模型进一步论证：
第一组模型
一共有4个线程，同时发了4笔请求，其中3笔耗时1s，一笔耗时2s，整个过程一共耗时2s。
公式1：
平均响应时间 = （1+1+1+2）/ 4= 1.25s ;
并发 = nL/T =4*1.25/2 =2.5
吞吐量 = 2.5 / 1.25 = 2 笔/s
公式2：
吞吐量 = 总笔数/总耗时 = 4/2= 2 笔/s
第二组模型
一共有4个线程，同时发了4笔请求，4笔请求耗时均为1s，1s内全部发送完毕。
公式1：
平均响应时间 = （1+1+1+1）/ 4= 1s
并发 = nL/T =4*1/1 =4
吞吐量 = 4 / 1= 4 笔/s
公式2：
吞吐量 = 总笔数/总耗时 = 4 / 1= 4 笔/s
第三组模型
一共有4个线程，4笔请求耗时均为1s，但线程发送出现不同步现象，一共持续1.5s完成全部：
公式1：
平均响应时间 = （1+1+1+1）/ 4= 1s
并发 = nL/T =4*1/1.5 =2.67
吞吐量 = 2.67 / 1= 2.67 笔/s
公式2：
吞吐量 = 总笔数/总耗时 = 4 / 1.5 = 2.67 笔/s
从上图中看出，实际压测时，两个公式还是会有些微差别，这就是因为我们本来预想并发应该=工具线程数，但在压测过程中，实际并发发生了变化，我们再反推下实际的并发数
计算出的实际并发确实稍低于工具线程数。
结论
1、 在单接口压测时，我们用“请求总数/总时长”得到吞吐量；然后再用“吞吐量*平均响应时间”得到实际并发，此举可用来观察系统实际承受的并发；
2、 在多接口压测时，由于短板效应，同一个流程中的所有接口获得的请求总数和总时长都一样，显然“请求总数/总时长”计算各个子接口的吞吐量不合适，所以改用“并发/平均响应时间”，其中的并发数应在压测工具中埋点统计，不可简单使用工具线程数。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/176547.html原文链接：https://javaforall.net
