1、性能测试（性能工程）概念

通过分析业务逻辑和技术架构，创建性能模型，制定性能方案，准备应用环境，设计并实施性能部署监控，实现符合真实业务逻辑的压力，通过监控手段获取各组件的性能计数器，分析计数器采集出的数据，查找出性能瓶颈的根本原因并优化，最后通过环比生产环境的性能数据修正场景。

2、按过程理解性能测试（性能工程）

2.1、业务分析&架构分析

2.2、性能需求指标

2.2.1、时间指标
2.2.2、容量指标
2.2.3、资源利用率指标

2.3、性能模型

2.3.1、业务模型
2.3.2、监控模型

2.4、性能方案

2.4.1、测试环境
2.4.2、测试数据
2.4.3、测试模型 - 基于业务模型构造测试数据
2.4.4、性能指标
2.4.5、压力测试-阶梯压力测试&高并发压力测试
2.4.6、准入准出
2.4.7、进度风险

2.5、环境准备

2.5.1、软硬件环境（包括压力机）
2.5.2、应用版本
2.5.3、基础设施
2.5.4、网络结构
2.5.5、基础数据
2.5.6、压力工具

2.6、性能监控

2.6.1、系统监控
2.6.2、中间件监控
2.6.3、缓存监控
2.6.4、队列监控
2.6.5、负载均衡监控
2.6.6、熔断限流
2.6.7、链路监控

2.7、性能场景执行

2.7.1、基准场景
2.7.2、容量场景
2.7.3、稳定性场景
2.7.4、异常场景

2.8、性能结构

2.8.1、场景结果整理
2.8.2、监控结果整理
2.8.3、性能整体分析
2.8.4、性能结论
2.8.5、优化建议
2.8.6、运维建议

2.9、生产运维

3、性能测试拐点图

最初版性能测试拐点图.png
经过几年发展后的性能测试拐点图.png

• A点之前：在TPS增加的过程中，响应时间一开始会处在较低的状态。

• B点：响应时间开始有所增加，直到业务可以承受的时间点B，这时TPS仍然有增长的空间。

• C点：再接着增加压力，到C点时，达到最大TPS。

• D点：我们再接着增加压力，响应时间接着增加，但TPS会有所下降（请注意，这里并不是必然的，有些系统在队列上处理的很好，会保持稳定的TPS，最后多出来的请求都被友好拒绝。）

• E点：最后，响应时间过长，达到了超时的程度。

4、性能测试分类

性能验证：验证系统是否达到指定的指标。 举例：RT是300ms,QPS/TPS是否可以达到800。
性能调优：验证是否达到系统的最大容量。 举例：限制或者不限制RT、内存水位、CPU水位，QPS/TPS可以达到多少。
容量验证：需要多少台机器。 举例：50 w UV,需要配置多少台机器。

5、性能测试场景

5.1、基准场景：把单接口或者单业务压到最大TPS，然后来分析单接口和单业务的瓶颈点在哪里。

5.2、容量场景：按业务比例进行压测。容量场景的最大TPS是指最大的稳定TPS。

5.3、稳定性场景：两个关键点：稳定性场景的时长&用多大的TPS来执行。在执行稳定性场景时，完全可以用最大的稳定 TPS 来运行，只要覆盖了运维周期之内的业务容量即可。

5.4、异常场景：宕主机、宕网卡、宕容器、宕应用等。

6、性能测试指标

6.1、业务指标：

1000万的用户，在场景A中，业务1占比10%，业务2占比20%，业务3占比30%；
1000万的用户，在场景B中，业务1占比20%，业务2占比30%，业务3占比40%；
1000万的用户，在场景C中，业务1占比30%，业务2占比40%，业务3占比50%。

6.2、技术指标：

1）时间指标(RT)：

包括接口响应时间+业务响应时间
参考：
互联网企业：500ms以下，例如淘宝业务10ms左右。
金融企业：1s以下为佳，部分复杂业务3s以下。
保险企业：3s以下为佳。
制造业：5s以下为佳。

2）容量指标(TPS/QPS)：

包括接口容量+业务容量

如果是接口层性能测试，TPS中的T 可以直接定义为接口级；
如果业务级性能测试，TPS中的T 可以直接定义为每个业务步骤和完整的业务流；

举例：

第一个例子：接口级脚本（单个接口）：

start事务（接口1）
商品详情页接口A
end事务（接口1）
start事务（接口2）
商品详情页接口B
end事务（接口2）

第二个例子：业务级脚本（每个业务步骤和完整的业务流）

start事务（业务A）
加入购物车（接口1）-下单（接口2）-支付（接口3）
end事务（业务A）

第三个例子：用户级脚本

start事务（业务A）
点击-加入购物车（接口1）-下单（接口2）-支付（接口3）
end事务（业务A）

3）资源利用率指标：

a、操作系统：CPU、Memory、Network、IO、System、Swap
b、JVM：GC、classes
...

4)并发用户数（VU）

对于长连接来说，最大并发用户数即系统的并发接入能力。实际上，就算是长连接，如果实际业务已经丢掉了异常的请求，那么最大并发用户数不等于系统的并发接入能力。
对于短连接来说，最大并发用户数并不等于系统的并发接入能力。

5)错误率（FR/ER）

7、并发、在线和TPS

并发是在单位时间内完成的事务（T）的个数。

在线用户数和压力线程之间的关系：

• 用请求级 TPS 计算：压力线程=(在线用户数×单用户请求数)/峰值采样时间段÷一个压力线程的请求级TPS

• 用单业务操作级 TPS 计算：压力线程=(在线用户数×单用户业务操作数)峰值采样时间段÷一个压力线程的业务操作级TPS

• 用用户级 TPS 计算：压力线程=(在线用户数×单用户完整业务数(也就是1)峰值采样时间段÷一个压力线程的用户级TPS

• 并发用户数的计算：并发用户数=在线用户数×无停顿时间的单线程TPS÷有停顿时间的单线程TPS

• 并发度：并发度=在线用户÷并发用户×100%（取值要在同一时间段）

从以上的计算逻辑中，我们可以看到，这其中有几个关键数据：

• 在线用户数。这个值可以从日志中取到；
• 在线用户数统计的时间段。这个值也可以从日志中取到；
• 用户级操作的完整业务流时间（记得多采样一些数据，计算平均时间）。这个值也是从日志中取到；
• 无停顿时间的完整业务流时间。这个值从压力工具中可以取到；
• 单用户完整业务流的请求数。这个值可以从日志中取到。

举例：
1)在线用户数：1个用户，100个请求，响应时间是250s

用户数：1个
响应时间：250s
请求数：100
tps计算： 1*100/250=0.4（请求数/秒）

在线用户数（有停顿时间）：100000个用户，100个请求，响应时间是3600s
用户数：100000个
响应时间：3600s
请求数：100
tps计算：100000100/3600=2777.8 tps

2)并发用户数（无停顿时间）：1个用户，100个请求，响应时间是6s

用户数：1个
响应时间：6s
请求数：100
tps计算：1*100/6=16.67 tps

3）压力线程=(在线用户数×单用户请求数)/峰值采样时间段÷一个压力线程的请求级TPS
压力线程 = 2777.8（100000在线用户的请求级TPS）/16.67（1个压力线程的请求级TPS）=167

4）并发用户数=在线用户数×有停顿时间的单线程TPS÷无停顿时间的单线程TPS
并发用户数 = 100000（在线用户数）*0.4（有停顿时间的单线程TPS）/16.67（无停顿时间的单线程TPS）=2399

5）并发度=在线用户÷并发用户×100%（取值要在同一时间段）
并发度 = 100000/2399*100%=41.68%

参考：高楼老师的课程