性能场景和性能需求指标

目录

一 性能场景

1、基准性能场景

2、容量性能场景

3、稳定性性能场景

4、异常性能场景

 二 性能需求指标

1、业务指标

2、技术指标

2.1 时间指标 RT

2.2 容量指标 TPS

2.3 资源利用率

3、指标之间的关系

“TPS”与“响应时间”

“用户数”与“TPS”与“压力工具中的线程数”

---

最近在网上搜索了很多性能测试的资料，都不能让我有深入的理解，直到看了高楼老师的《性能测试实战30讲》和《高楼的性能工程实战课》培训课程，才觉得对性能有了一个全貌的认知；

虽然做过几个性能测试项目，但是也仅仅局限在，就像老师所说“就是做些脚本、参数化、关联，压起来之后，再扔出一个结果。”

老师的课程内容很丰富，目前还在学习阶段，并不能完全消化理解，但是又想记录下来一些东西以加深理解，所以有了这篇文章，本文的描述和图片全部摘自老师的培训课程。

“性能测试”不仅仅包括测试，还包括分析和调优。

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

一 性能场景

1、基准性能场景

也可称之为单交易容量，即将每一个业务都压到最大TPS，从而为后续场景做数据比对。

2、容量性能场景

也可称之为混合容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程。

3、稳定性性能场景

核心就是时长。在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程。

1. 稳定性的时间长度要合理，也就是说要合理判断稳定性场景需要运行多长时间；
2. 稳定性使用的TPS量级要合理，也就是说我们要合理判断稳定性场景应该用多大的压力执行。

4、异常性能场景

显然就是异常的定义最为重要。之前我们常用的手段就是宕主机、宕应用、宕网卡。随着云基础架构的发展，现在我们还有宕容器、宕虚机、宕缓存、宕队列、宕集装箱、宕流控、宕熔断等等。实际的场景中要模拟什么样的异常，一定是根据系统的业务架构和部署架构分析而来的。不是看到什么都在宕一下。

 
二 性能需求指标

1、业务指标

所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。

2、技术指标

2.1 时间指标 RT

响应时间指的是客户端发出请求到得到响应的整个过程所经历的时间；

2.2 容量指标 TPS

TPS（Transactions Per Second），每秒事务数；

在性能测试过程中，TPS之所以重要，是因为它可以反应出一个系统的处理能力。

其中的T为事务，事务就是统计了一段脚本的执行时间，性能中TPS中T的定义取决于场景的目标和T的作用。

如果我们要单独测试接口1、2、3，那T就是接口级的；如果我们要从用户的角度来下一个订单，那1、2、3应该在一个T中，这就是业务级的。

接口级脚本	——事务start（接口1） 接口1脚本 ——事务end（接口1）
	——事务start（接口2） 接口2脚本 ——事务end（接口2）
	——事务start（接口3） 接口3脚本 ——事务end（接口3）
业务级接口层脚本 （就是用接口拼接出一个完整的业务流）	——事务start（业务A） 接口1脚本 - 接口2（同步调用） 接口1脚本 - 接口3（异步调用） ——事务end（业务A）
用户级脚本	——事务start（业务A） 点击0 - 接口1脚本 - 接口2（同步调用） 点击0 - 接口1脚本 - 接口3（异步调用） ——事务end（业务A）

2.3 资源利用率

CPU 内存 IO 网络；

3、指标之间的关系

“TPS”与“响应时间”

图中蓝线表示TPS，黄色表示响应时间。

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

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

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

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

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

“用户数”与“TPS”与“压力工具中的线程数”

上面的一个框中有四个箭头，每个都代表着相同的事务。

在上面这张示意图中，其实压力工具是4个并发线程，由于每个线程都可以在一秒内完成4个事务，所以总的TPS是16。

对在线的用户做并发度的分析，在很多业务中，并发度都会低于5%，甚至低于1%。

拿5%来计算，就是10000用户x5%=500(用户级TPS)，注意哦，这里是TPS，而不是并发线程数。

如果这时响应时间是100ms，那显然并发线程数是500TPS/(1000ms/100ms)=50(并发线程)。

但是！响应时间肯定不会一直都是100ms的嘛。所以通常情况下，上面的这个比例都不会固定，而是随着并发线程数的增加，会出现趋势上的关系。