性能测试中性能指标怎么确定？

前段时间遇到两个问题，1，性能指标怎么来的？2，TPS如何转化为在线用户数？感觉没有回答清晰，于是结合之前实践先说说问题1。

Q：性能指标的确定

总共分为4个步骤：确定性能目标 --> 分析业务背景 --> 确定场景类别 --> 确定性能指标

确定性能目标

首先性能指标是根据性能需求场景来的，而性能需求场景的目标一般分为3类：

1. 性能验证
   评估下系统能支持的最大容量，如测试当前下单支持多少并发、测试当前系统支持多少在线用户等
2. 性能调优
   测试并优化系统以支持线上的业务目标，如要求系统需要支持100万用户在线、支持1万用户并发等
3. 性能推算
   测试并评估未来几年内，性能容量是否可以满足业务发展。如系统在1年后能否支持1000万在线用户等

分析业务背景

接着我们开始分析业务背景，业务背景主要关注：

1. 明确被测系统业务类型，是银行业务、电商业务、还是其他活动业务？这里业务方一般会给出业务目标，比如预期的在线用户数，PV，UV，GMV等目标
2. 当前业务类型下，有哪些业务场景，对应业务场景的用户操作业务流是什么？以及对应的流量转化模型？可由业务方给出
3. 是否有历史数据支撑，作为当前业务的参考，比如是否存在历史性能问题、历史流量峰值

确定场景类别

性能场景分为4类：1，基准场景；2，容量场景；3，稳定性场景；4，异常场景

1. 目标是性能验证：
   如果是测试具体操作业务，我们只需要做基准场景（如当前下单支持多少并发类似需求）。如果是系统级别的需要考虑业务模型，我们除基准场景外还需要做容量场景（如当前系统支持多少在线用户等需求），而稳定性性能场景与异常性能场景根据实际情况做取舍
2. 目标是性能调优
   需要依次做基准场景、容量场景，稳定性场景，异常场景。其中测试对象是当前系统、当前业务模型、当前场景
3. 目标是性能推算
   需要依次做基准场景、容量场景，稳定性场景，异常场景。其中测试对象是未来系统、未来业务模型、未来场景

确定性能指标

确定需要测试的性能场景与业务目标后，分析并得到性能指标具体对应到各个场景中（这里需要与业务、产品、开发等一起确定）

业务指标换算

1，对于新系统

• 先统计在线用户数，需预判系统将要承载的在线用户数，可通过业务目标推算（没有业务目标，根据经验估算）
• 接着计算出并发度，可参考行业系统类型的并发度，如5%

并发度 = 响应时间 / (响应时间+思考时间) * 100%

• 再计算并发用户：并发用户 = 在线用户数 * 并发度
• 设定各业务平均响应时间，用户操作的业务流中各业务的可接受响应时间可能不一样
• 最后估算TPS，在稳态条件下，根据Little定律，TPS = 并发用户数 / 业务平均响应时间（注意：这里的T指的是用户级别的事务）

举例：一个系统上线后日常在线用户数量要支撑10000，那么并发用户参考值为：10000 * 5%=500。规定某业务的平均响应时间不高于500毫秒，那么TPS = 并发用户数 / 业务平均时间 = 500 / 0.5s = 1000笔/秒。考虑系统健壮性，可拔高1.5倍即1000笔 / 秒 * 1.5=1500笔/秒。
即可得到该系统某业务的TPS为1500笔/秒，并发数为500。

2，对于已上线系统

• 先统计生产业务日志，根据时间维度（年-月-日-时-分-秒）划分实际请求量，并依次选取各维度的峰值时间段，来抽取日志中的各请求分布比例

这里时间维度是细化到时、分还是秒，需要考虑两个要求：一是需要细化后的请求量级尽可能低，二是统计的时间段需要覆盖主要业务流程

• 在峰值时间段下，每个时间点下各请求分布比例一致的作为一个通用业务场景，其他时间点部分接口分布突出的作为补充业务场景
• 在各个业务场景中，找到峰值业务时间段，根据实际请求量，细化时间段，并统计该时间段的总请求数
• 计算当前业务场景的TPS，TPS = 总请求数 / 统计时间（注意：这里的T指的是接口级别的事务）
• 统计当前业务场景的各接口比例，作为该业务场景的业务模型
• 根据业务逻辑，计算出当前业务场景的TPS下完整走完业务的用户比例（该用户比例本质上对应的是并发用户）

举例：一个系统上线后，根据系统业务类型或者活动时间，选择大流量的时间段，比如11月11号。
1，根据当天的业务访问日志（nginx日志），使用脚本生成全体时间段的各接口分布比例柱形图（比如A接口、B接口、C接口等每隔5分钟的全天请求次数柱形图）。
2，根据柱形图发现各接口在全天时间段的接口分布情况基本一致，那么就只需要测试一个通用业务场景。
3，于是选择A接口的峰值流量的时间段（比如早上10-11点），再按照10分钟细化这小时的流量（接口密集可细化到秒，甚至毫秒），统计峰值的某10分钟段的总请求数假如为12000。
4，那么生产TPS=12000/600=20笔/秒，这时的TPS可以作为容量场景的目标TPS（如果当前应用版本有业务增量，需要增加对应增量）。
5，接下来统计当前业务场景的各接口比例，后续作为容量场景的业务模型需要实现到场景脚本中。
6，最后顺便分析当前接口比例中，完成完整业务流程的用户比例占多少（比如登录比例是12%，后面下单比例是7%，那么大概是7%/12%=58%的用户会走完流程），这个值对后续容量估算有用。
按照上述步骤即可得到该系统的通用业务容量场景的TPS为20笔/秒。

场景指标确定

我们知道性能基准场景包括业务指标（TPS、响应时间、交易成功率、99%响应时间、响应时间方差等）和技术指标（CPU使用率、内存使用率等）

由于技术指标细化下来可能存在多个制约条件，优先考虑业务指标

另外容量场景会多两个指标：业务对应的比例及总TPS；稳定性场景会多一个测试时间；异常场景的指标主要是对应的异常验证点及错误率的容忍度

对于基准场景

1. 测试对象是新系统

• 如果有业务目标，根据在线用户数与并发度计算出并发用户数，再根据每个业务的响应时间再计算出各业务的TPS指标
• 如果没有业务目标，那么TPS可以按照经验值确定（如8H16G的机器一般登录接口TPS应该能达到2000，业务复杂的至少500以上）

响应时间需要考虑业务复杂度，一般在线实时交易响应时间：
互联网企业：500毫秒以下，例如淘宝业务10毫秒左右
金融企业：1秒以下为佳，部分复杂业务3秒以下
保险企业：3秒以下为佳
制造业：5秒以下就行

2. 测试对象是已上线系统
   已上线系统应该有线上日志，那么根据上述业务指标换算中已上线系统情况，在第一步操作每个接口的峰值TPS就会统计出来，可以在该峰值TPS上拔高1.5倍作为TPS指标

对于容量场景

对于容量场景来说，最重要的就是业务比例，也就是我们经常说的业务模型

1. 测试对象是新系统
   由于新系统的业务模型是未知的，所以评估的容量TPS并不能准确反映线上真实情况，可以等后续试运行后，得到了业务模型再次测试

个人理解业务模型包含三部分：用户分布模型，用户行为模型，业务流量转化模型。
对于用户确定、业务逻辑简单并且业务方给出了流量转化模型的系统，可以根据上述新系统的业务指标换算出并发用户数，再根据总业务的平均响应时间（统计多次手动实验平均值），初步评估系统的容量TPS，然后根据流量转化模型，设置各接口的业务比例。

2. 测试对象是已上线系统
   已上线系统应该有线上日志，那么根据上述业务指标换算中已上线系统情况，统计并计算出业务场景的业务比例与容量TPS，可以在该容量TPS上适当拔高作为TPS指标

对于稳定性场景

在容量场景完成后，稳定性场景需要选择合理的TPS和场景运行时间。

1. 稳定性场景的目标是保障系统的业务积累量的稳定性，直接用容量场景最大 TPS 来运行即可
2. 稳定性的时间长度要合理，需要根据运维周期下的业务积累量来计算，即T= 业务积累量 / TPS / 3600（秒）

举例：你的系统一个月有1000 万的业务累积量，同时稳定性运行的指标是稳定运行三个月，则运行时长 T= 3000万 / 1000TPS / 3600秒 = 8小时

异常场景

根据行业技术市场，异常场景测试主要考虑应用异常、操作系统异常、容器异常和虚拟机异常，一是看系统是否能够快速恢复，二是看系统恢复时的错误率是否能够接受

1. 针对应用异常
   根据系统架构，设计异常场景，比如微服务的限流与降级熔断，可以根据业务情况，设定TPS或者响应时间进行限制验证，需要注意的是限制增删后，系统能不能正常处理与恢复。
2. 针对操作系统异常
   可以从CPU、内存、网络、磁盘四个角度来模拟操作系统中的异常，需要注意的是异常出现后，系统能不能快速恢复

其中CPU异常包括：1，在应用中模拟业务线程之间抢 CPU 的异常；2. ，在同一台机器上的其他进程抢被测业务进程的 CPU
内存异常模拟其他进程的内存抢占
网络异常可以使用延迟与丢包
磁盘异常可模拟其他进程的大量随机读写

3. 针对容器异常
   针对K8S容器架构，可以测试Kill容器与驱逐容器两种情况，需要注意的是异常出现后，系统恢复时的错误率是否能够接受

4. 针对虚拟机异常
   针对虚拟机 KVM架构，可以测试Kill虚拟机情况，需要注意的是异常出现后，系统恢复时的错误率是否能够接受

---

参考文章：
评估一个系统TPS与并发数
如何确定性能测试指标
高楼的性能工程实战课