性能测试基础

一、基本概念

性能测试针对系统的性能指标，建立性能测试模型，指定性能测试方案，指定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出的性能结果来评估系统的性能指标是否满足既定值。

1.性能指标：时间指标、容量指标、资源利用率指标

2.模型：真实场景的抽象，告诉性能测试人员，业务模型的样子。目前很多模型直接从线上流量导入过来

3.方案：测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险

4.监控：要有分层、分段的能力，要有全局监控、定向监控的能力

5.预定条件：软硬件环境、测试数据、测试执行策略、压力补偿等。比如说，我们判断 CPU 使用率达到 80% 或 I/O 响应时间达到 10ms 时，就做动态扩展。

6.性能场景：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

性能场景分类：

1）.基准性能场景：做单交易的容量，每一个业务都压到最大TPS，从而为混合容量做基准数据准备，保证单交易业务容量不会成为混合容量的瓶颈点（几个线程跑三五遍脚本不能称作为基准测试，只能算作为预执行）。

2）.容量性能场景：也可称为混合容量性能场景，将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等配合下，分析瓶颈并调优的过程。最核心的性能执行部分，根据业务复杂度不同，设置多个场景。（性能测试、负载测试、压力测试、强度测试、容量测试、极限测试、性能评测测试、性能调优测试、并发测试、综合场景测试、递增测试、内存泄漏测试、数据容量测试、极限测试、配置测试）。

3）.稳定性性能场景：在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程。稳定测试中，最核心元素是时间，时间的设置来自于运维周期。（疲劳强度测试、稳定性压力测试）

4）.异常性能场景：在压力流量下，模拟异常。常用手段宕主机、宕应用、宕网卡。随云基础架构的发展，目前还有宕容器、宕虚拟机、宕缓存、宕队列、宕集装箱、宕流控，宕熔断等。实际场景中根据系统的业务架构和部署架构分析而来。（破坏性压力测试）

7.分析调优：根据不同的项目决定要不要性能调优

1）.新系统性能测试类：项目一般都会要求测试出系统的最大容量

2）.旧系统新版本性能测试类：和旧版本对比，性能不下降

3）.新系统性能测试优化类：不仅要测试出最大容量，还要求调优到最好

8.结果报告：监控，场景执行的过程，产生的数据，调优前后的 TPS、响应时间以及资源对比图，然后汇报或者归档。

二、TPS和响应时间

1.常见分析

三条曲线：吞吐量的曲线（紫色）、使用率 / 用户数曲线（绿色）、响应时间曲线（深蓝色）。

三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。

两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。

三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。

图中与实际之间存在一定的误差，资源使用率达到饱和之后还有一段时间的TPS才会达到上限。

最大并发数肯定在性能衰减之前。

具体项目实施中TPS以服务端处理请求数为准而不是压力工具中的线程数。

上图中蓝线表示 TPS，黄色表示响应时间。在 TPS 增加的过程中，响应时间一开始会处在较低的状态，也就是在 A 点之前。接着响应时间开始有些增加，直到业务可以承受的时间点 B，这时 TPS 仍然有增长的空间。再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有下降（请注意，这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝）。最后，响应时间过长，达到了超时的程度。

上述逻辑关系更符合真实场景。

性能场景必须要连续，是为了递增线程数，记录每次的性能指标，对比分析，画曲线，来观察指标变化的趋势，找出性能瓶颈，或者服务器最大处理能力

三、理解常见性能指标

简写	英文全称	含义
RT	Response Time	响应时间。通常我们说的响应时间，都是包括了Request Time和Response Time
HPS	Hits Per Second	每秒点击数
TPS	Transaction Per Second	每秒事务数
QPS	Queries Per Second	在MySQL中指每秒SQL数
RPS	Request Per Second	每秒请求数
CPS	Codes Per Second	在HTTP协议中，CPS偶有提及，指HTTP返回码每秒
PV	Page View	页面浏览量
UV	Unique Visitor	独立访问者
IP	Internet Protocol	本意IP地址，在性能中一般指独立IP数
Throughput	/	吞吐量
IOPS	Input/Output Operations Per Second	通常描述磁盘

TPS：根据场景目的来定义TPS粒度，如果接口层性能测试，T定义为接口级；如果业务级性能测试，T可以定义为每个业务步骤和完整业务流。

用户数、线程数和TPS之间关系

 500TPS/(1000ms/100ms)=50(并发线程)：对一个线程来说，如果响应时间是100ms，那这个线程在一秒内不就是：1000ms/100ms = 10tps，如果要达到500TPS，那需要多少线程呢？就是500TPS/10TPS=50线程。

上诉比例不是固定不变的，而是随着并发线程数增加，出现趋势上的关系。

1.业务模型如何获取：

1）.根据生产环境的统计信息做业务比例的统计，然后设定到压力工具中，很多不能再线上直接做压力测试的系统，都通过这种方式获取业务模型。

2）.直接在生产环境中做流量复制的方式或者压力工具直接对生产环境发起压力的方式做压力测试。这种方式被很多人称为全链路压测。其实在生产中做压力测试的方式，最重要的工作不是技术而是组织协调能力。

2.响应时间设计：

1）.同行业的对比数据

2）.找到使用系统的样本用户，对他们做统计，将结果拿出来。

3.性能指标的计算方式：系统容量的预估，不能简单的套用简单计算公式，是需要根据现有的数据，做统计分析、做排队论模型，进而推导以后的系统容量。

性能测试概念中：性能指标、性能模型、性能场景、性能监控、性能实施、性能报告。

性能场景中：基准场景、容量场景、稳定性场景、异常场景。

性能指标中：TPS、RT。 （记住 T 的定义是根据不同的目标来的）

四、工具选择

工具选择考虑：

1.学习成本：对人员水平要求，培训时间成本等

2.脚本编写：能否录制测试脚本，是否支持GUI操作等

3.安装部署成本：是否支持一键安装，是否支持docker

4.是否免费：开元工具一般免费，但很多收费工具也是物有所值

5.是否支持多协议：比如是否支持HTTP，RPC协议等

6.测试场景：是否有链路、场景编排管理，支持将请求编排成业务场景

7.流量控制：支持纵向的，上下游链路的请求量逐渐减少，整体呈现一个漏斗模型；也可以是横向；

8.压力控制：压测时并发用户数、TPS的控制等

9.数据驱动：大量的测试数据的参数化

10.分布式支持：支持压力机集群

11.测试报告：压测结果是否能够图形化显示，提供美观且丰富的测试报告

12.二次开发成本：由于时间和人力关系，需要考虑二次开发成本

13.性能开销：执行机开销、软件可靠性、执行效率、业务处理能力等

五、并发用户数计算

在线最大用户数，直接拿缓存的内存计算，如：

一个用户进入系统，需要10K内存维护用户信息，那么10G内存就能hold 1048576个用户数据，这个就是最大用户数，在实际项目中，我们还会将超时放在一起考虑。

TPS=1000ms/响应时间（单位ms）*压力机线程数

对于压力工具来说，只要不报错，我们就关心TPS和响应时间就可以了，因为TPS反应出来的是服务器对应的处理能力，至少压力线程数是多少，并不关心。

如果在一个微服务的系统中，因为每个服务都只做一件事情，拆分得很细，我们要注意整个系统的容量水位，而不是看某一个服务的能力，这就是拉平整个系统的容量。

并发度计算：

1.统计某时段的当前在线用户数

2.统计某一时间段的操作某功能的用户数

3.把所有功能操作的用户数统计出来

4.将统计出来的用户数除以在线用户数就是并发度了

算好并发度就不需要设置思考时间了

六、性能分析思路

性能分析能力阶梯视图

1.工具操作：压力工具、监控工具、剖析工具、调试工具

2.数值理解：上面工具中所有输出数据

3.趋势分析、相关性分析、证据链分析：理解了工具产生的数值之后，还要把它们的逻辑关系想明白，这是性能测试分析最重要的一环。

4.调优：有了第三步，调优方案策略就有很多种了，具体取决于调优成本和产生的效果。

性能分析思路

1.瓶颈精准判断

TPS曲线可以告诉我们

1）.有没有瓶颈：准确的说，每个西永都有性能瓶颈，只看我们再哪个量级做性能测试

2）.瓶颈和压力有没有关系：TPS随着压力的变化而变化，那就有关系。不管压力是否增加，TPS都会出现曲线趋势问题，那就无关。

响应时间是用来判断业务有多快，而TPS才是用来判断容量有多大的。

对于一个系统来说，如果仅改变压力策略（其他条件比如环境、数据、软硬件配置等都不变）的情况下，系统的最大TPS上限是固定的。

我们设计场景应该选择递增的策略，使用过程中需要注意的点：

1）.场景中线程递增一定是连续的，并且在递增的过程中也是有梯度的

2）.场景中线程递增一定要和TPS的递增有比例关系，而不是突然达到最上限。比例关系后续说明

3）.上面两点针对的常规的性能场景。对于秒杀类的场景，我们前期一定是做好了系统预热的工作，预热之后，线程突增产生的压力，也是在可处理范围的。这时，我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增，就是不合理的场景。

性能场景递增经验值：仅供参考，需要根据实际测试过程来做相应判断

响应时间	递增幅度
0-50ms	1
50-100ms	1-3
100-200ms	3-5
200-500ms	5-10

在每个阶梯递增的过程中，出现了抖动，这就是明显系统设置不合理导致的。设置不合理两种可能性：

1）.资源的动态分配不合理，像后端线程池、内存、缓存等等

2）.数据没有预热

2.性能衰减过程

只要每线程每秒的TPS开始变少，就意味着性能瓶颈已经出现了，但是瓶颈出现之后，并不是说服务器的处理能力会下降，应该说TPS仍然会上升，在性能不断衰减的过程中，TPS就会达到上限。

当性能衰减到最大TPS，根据我们场景目标决定要不要停止场景。如果我们是为了得到最大TPS，那就可以停止了。但是如果我们要扩大性能瓶颈，让瓶颈更为明显，就完全不需要停止场景，只要不报错就往上压。一直压到响应时间变长，需要拆分。

3.响应时间的拆分

只要系统达到瓶颈，再加压力，肯定会导致响应时间上升，直到超时未止。

判断了瓶颈之后，我们需要找到问题出现在什么地方，响应时间变长，我们需要知道在哪个阶段变长了。

通过链路监控或者抓包等手段进行分析每个环节消耗时间，为构建分析决策树做准备

4.构建分析决策树

分析决策树是性能分析中不可或缺的一环，它是对架构的梳理，对系统的梳理，对问题的梳理，对查找证据链过程的梳理，是对分析思路的梳理。它纵观全局，为高屋建瓴做指导。

例：

MySQL

操作系统

性能测试工程师要做的就是一步步细化分析，给出最终的原因

5.场景比对

对架构并不复杂的系统，当你觉得哪个环节不行，又没有能力分析它的时候，你可以直接做该环境的增加。