3. 性能测试之目标评估

---

前言

在性能测试中，经常会遇到项目经理，运维或甲方客户咨询这样的问题：
咱们的xxx系统是否能抗住20w的日活呢？
最近我们要上一个活动，引流100w进来，系统是否能扛得住？
咱们的系统是否可支撑1000并发？
xxx业务需要申请多少台服务器合适呢？

想要解决这些问题，就必须先学会怎样由业务场景评估性能目标，然后再梳理出具体的测试场景，执行测试得出数据与目标对比，用数据给出具有说服力的答案

以下介绍常见的4种不同性能目标评估模型

---

一、模型1：根据日活计算目标QPS

1. 原则

原则：2-8原则
即：20%的时间内完成80%的用户请求数
目标QPS的计算：总请求数 $\ast$ 80%/用户时间段 $\ast$ 20%
目标QPS=（日活用户数 $\ast$ 每个用户每天在系统中产生的请求数 $\ast$ 0.8）/（ 用户时间段 $\ast$ 3600 $\ast$ 0.2）
备注：乘以3600是为了换算成秒
所以：要评估目标QPS，需要知晓日活，业务对应的用户时间段，每个用户每天在系统中产生的请求数

2. 事例

场景：xxxApp上线了核酸预约功能，是否可支撑40w的日活
解析：
经实际抓包分析，用户从打开App到完成核酸预约功能，共涉及15个核心接口
假设每个用户每天访问3次核酸预约功能，则
40w的日活每天产生的总请求数：40w $\ast$ 15 $\ast$ 3=1800w
因核酸预约业务是全天候的且用户使用时间段集中9:00–17:00，共8h
故根据2-8原则，计算出目标QPS，如下：
目标QPS=(1800w $\ast$ 0.8 ) / (8 $\ast$ 3600 $\ast$ 0.2)=3125
所以要想支撑40w的日活，核酸预约功能的QPS至少应在3125以上

---

二、模型2：根据压测数据评估最大支撑并发

1. 原则

原则：QPS $\ast$ 平均响应时间(s)约等于并发
即：拐点并发 / 拐点平均响应时间 ≈ 最大可支撑并发 / 最大可接受响应时间
即：最大可支撑并发=拐点并发*最大可接受响应时间/拐点平均响应时间
备注：
1.拐点并发和拐点平均响应时间是指在性能测试过程中，出现第一个拐点即QPS拐点时，对应的并发和平均响应时间
2.该评估模型适用于性能平稳阶段的最大可支撑并发

可以参考《2.性能测试的本质》中这幅图，估计就更好的理解了

2. 事例

用户登录接口，测出拐点QPS时，性能如下：
并发100时，qps：1000，平均响应时间：100ms，错误率：0.00%
所以
若用户最大可接受的响应时间为1s，估算可能可支撑并发：100 $\ast$ 1 / 0.1=1000
若用户最大可接受的响应时间为3s，估算可能可支撑并发：100 $\ast$ 3 / 0.1=3000
若用户最大可接受的响应时间为5s，估算可能可支撑并发：100 $\ast$ 5 / 0.1=5000

估算的是否准确，是需要进行一轮的真实测试，获得更真实可靠的数据

3. 备注

该模型的常见使用场景是，根据目标响应时间，评估出发压的最大并发值，然后再根据评估的最大并发值实际发压，验证是否满足目标响应时间

备注：这个过程中还要关注错误率，如果错误率已经不达标了，那就需要及时停止加压

---

三、模型3：根据压测数据评估服务器资源

1. 策略

结合目标QPS与现有系统的测出的实际QPS，估算系统所需的服务器数目
例：用户系统目标QPS为1000，现有的压测结果: 单台4C4G的服务器，用户系统性能QPS:600，问若要满足目标QPS, 则服务器配置？
建议配置：2台4C4G的服务器或1台8C8G的服务器
建议策略：扩容后再压测一轮，确保新增服务器后，性能能达标
因为有时性能不一定随着服务器的递增而线性递增的

2. 备注

该情况比较适用于性能瓶颈是因为服务器资源不足而导致的上不去，扩容肯定会有效果，但是如果性能瓶颈是在代码逻辑上，这时这种方式评估服务器资源可能就有较大误差

---

四、模型4：评估用户并发或峰值并发

看到有网友分享如下的公式：
估算平均并发和峰值并发
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3*根号C

C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度，C’是峰值并发

但是在实际的应用场景中，感觉最常用的还是如下评估方法
(用户总量/统计时间) $\ast$ 影响因子（一般为3）来进行估算并发量

例：以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000 $\ast$ 80%/（3 $\ast$ 60 $\ast$ 60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s $\ast$ 3s=12，当然影响因子可以根据实际情况增大！

---

总结

通过这四种模型，我们就可以根据日活计算目标QPS与峰值并发，根据压测数据评估最大支撑并发，也可根据压测数据评估出业务需要的最优服务器资源，进一步的把抽象的目标转化了更具象的目标，为性能压测场景的制定奠定了基础