当我们谈论系统性能测试时，具体谈论的是什么？

本文为博主自学笔记整理，内容来源于互联网，如有侵权，请联系删除。

个人笔记：https://github.com/dbses/TechNotes

01丨性能测试是什么样的？

性能测试要有指标

时间指标、容量指标、资源利用率指标。

性能测试要有模型

业务模型，比如说，我们有 100 种业务，只有 50 个业务需要有并发量，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力测试时就要控制好这样的比例。

监控模型，这个部分的监控，要有分层、分段的能力，要有全局监控、定向监控的能力。

性能测试要有方案

方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。

性能测试要有预定的条件

这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。要是展开来说，在场景执行之前，这些条件应该是确定的。

性能测试中要有场景

1. 基准性能场景
2. 容量性能场景
3. 稳定性性能场景
4. 异常性能场景

性能测试中要有分析调优

性能项目分以下几类：

• 新系统性能测试类

  这样的项目一般都会要求测试出系统的最大容量。

• 旧系统新版本性能测试类

  只要性能不下降，就可以根据历史数据推算容量。

• 新系统性能测试优化类

  这类系统不仅要测试出最大容量，还要求调优到最好。

对性能团队的职责定位有如下几种：

1. 性能验证
2. 性能测试
3. 性能测试 + 分析调做强

性能测试要有结果报告

在报告中写上 TPS、响应时间以及资源对比图。

02 | TPS和响应时间之间是什么关系？

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

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

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

再接着增加压力，达到 C 点时，达到最大 TPS。我们再接着增加压力，响应时间接着增加，但 TPS 会有所下降。

这里并不是必然的，有些系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝。

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

在实际的性能测试中，基准性能场景也好，容量性能场景也好，都是需要递增的，而不是上来就用几百几千的线程。同时，递增也是要连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景。

性能场景为什么要连续？而不是断开？

递增线程数可以记录每次的性能指标，画曲线对比分析，来观察指标变化的趋势，找出性能瓶颈以及服务器最大处理能力。

03 | 系统性能指标有哪些？

性能测试行业常用的性能指标表示法。

简写	英文全称	含义
RT	Response Time	响应时间。通常我们说的响应时间，都是包括了Request Time和Response Time。
HPS	Hits Per Second	每秒点击数
TPS	Transactions Per Second	每秒事务数
QPS	Queries Per Second	在MySQL中指每秒SQL数
RPS	Requests 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 是性能领域中一个关键的性能指标概念，它用来描述每秒事务数，可以反映出一个系统的处理能力。TPS 在不同的行业、不同的业务中定义的粒度也是不同的。所以不管你在哪里用 TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。

以下图为例：

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

RPS

如果一个用户点击了一次，发出来 3 个 HTTP Request，调用了 2 次订单服务，调用了 2 次库存服务，调用了 1 次积分服务，那么这个 Request 该如何计算?

如果要描述整体，最多算是有 3 个 RPS。如果从 HTTP 协议的角度去理解，那么 HTTP Request 算是一个比较准确的描述了，但它本身的定义并没有包含业务。如果赋予它业务的含义，那么用它来描述性能也是可以的。

压力工具中的线程数（用户数）与 TPS

“并发”这个概念是需要具体的指标来承载的。

你可以说，我的并发是 1000TPS，或者 1000RPS，或者 1000HPS。但不能说并发 1000 这样没有单位的词。

以下图为例，来描述线程数与 TPS。

上图有 4 个并发线程，每个线程都可以在一秒内完成 4 个事务，所以总的 TPS 是 16。

那么用户数怎么来定义呢？一个系统如果有 1 万个用户在线，很多业务中，并发度都会低于 5%，甚至低于 1%。拿 5% 来计算，就是
$$10000用户\ast 5\%=500(TPS)$$
注意这里是 TPS 而不是并发线程数。如果这时响应时间是 100ms，那显然并发线程数是
$$500TPS/(1000ms/100ms)=50(并发线程)$$
通过这样简单的计算逻辑，我们就可以看出来用户数、线程数和 TPS 之间的关系了。