极客时间高楼老师的性能测试实战30讲学习笔记

性能测试概念

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

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

2. 性能测试模型： 模型是真实场景的抽象，可以告诉性能测试人员，业务模型是什么样子。比如说，我们有 100 种业务，但不是每个业务都需要有并发量，可能只有 50 个业务有，那就要把这些有并发的业务统计出来，哪个业务并发多，哪个业务并发少，做压力时就要控制好这样的比例。这种做法需要的数据通常都是从生产环境中的数据中统计来的。

3. 性能测试方案： 方案规定的内容中有几个关键点，分别是测试环境、测试数据、测试模型、性能指标、压力策略、准入准出和进度风险。基本上有这些内容就够了，这些内容具体的信息还需要精准。

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

5. 性能测试预定条件： 这里的条件包括软硬件环境、测试数据、测试执行策略、压力补偿等内容。在场景执行之前，这些条件应该是确定的。

6. 性能测试场景： “性能场景”这个词在性能测试中占据着举足轻重的地位，对性能场景中的“场景”比较正宗的描述是：在既定的环境（包括动态扩展等策略）、既定的数据（包括场景执行中的数据变化）、既定的执行策略、既定的监控之下，执行性能脚本，同时观察系统各层级的性能状态参数变化，并实时判断分析场景是否符合预期。

   性能场景的分类： 1.基准性能场景：这里要做的是单交易的容量，为混合容量做准备 2.容量性能场景：这一环节必然是最核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多。 3.稳定性性能场景：稳定性测试必然是性能场景的一个分类。只是现在在实际的项目中，稳定性测试基本没和生产一致过。在稳定性测试中，显然最核心的元素是时间（业务模型已经在容量场景中确定了），而时间的设置应该来自于运维周。 4.异常性能场景：要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。

   

7. 性能测试分析调优： 根据实际具体性能测试项目需求决定是否需要进行调优

8. 性能测试结果报告： 有了前面监控的定义，有了场景执行的过程，产生的数据就要整理到结果报告中了。这个文档工作也是很重要的，是体现性能团队是否专业的一个重要方面。大部分老板或者上司关心的是测试的结果，而不是用了多少人，花了多少时间这些没有意义的数字。我们更应该在报告中写上调优前后的 TPS、响应时间以及资源对比图。

总结图：

TPS与响应时间之间的关系

TPS（系统吞吐量），是最能直接体现软件系统负载承受能力的指标，所有对吞吐量的讨论都必须以“单位时间”作为基本前提。对性能测试而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”来衡量吞吐量。

响应时间，反映了完成某个操作所需要的时间，其标准定义是“应用系统从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间”，是用户视角软件性能的主要体现。响应时间，分为前端展现时间和系统响应时间两部分。其中，前端时间，又称呈现时间，取决于客户端收到服务器返回的数据后渲染页面所消耗的时间；而系统响应时间，又可以进一步划分为 Web 服务器时间、应用服务器时间、数据库时间，以及各服务器间通信的网络时间。

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

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

性能需求指标

通常我们都从两个层面定义性能场景的需求指标：业务指标和技术指标。这两个层面需要有映射关系，技术指标不能脱离业务指标。如下示意图所示，描述了业务指标和性能指标之间的关系： TPS在不同的行业、不同的业务中定义的粒度都是不同的。通常情况下，我们会根据场景的目的来定义 TPS 的粒度。如果是接口层性能测试，T 可以直接定义为接口级；如果业务级性能测试，T 可以直接定义为每个业务步骤和完整的业务流。

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

性能测试工具

性能测试中，工具仅仅是发起压力的工具，关键是通过发起压力后拿到的数据。

近几年市面上流行的工具总结：

毫无疑问，Jmeter是性价比最高的。LoadRunner仍然是性能测试市场上，功能最为齐全的工具，没有之一。

Gatling 有免费版和收费版，基于 Scala 语言，而 Scala 又是基于 Java 的，你看这复杂的关系就让人不想用，但是这个工具性能很高，虽说只支持 HTTP，但是由于支持 Akka Actors 和 Async IO，可以达到很高的性能。Actors 简化并发编译的异步消息特性让 Gatling 性能很高。

计算并发数

用 TPS 来承载“并发”这个概念。如：并发数是 16TPS，就是 1 秒内整个系统处理了 16 个事务。

TPS=(1000ms/响应时间(单位ms))​∗压力机线程数

1. 通常所说的并发都是指服务端的并发，而不是指压力机上的并发线程数，因为服务端的并发才是服务器的处理能力。
2. 性能中常说的并发，是用 TPS 这样的概念来承载具体数值的
3. 压力工具中的线程数、响应时间和 TPS 之间是有对应关系的。

性能分析思路

性能测试能力梯度如下： 1.工具操作：包括压力工具、监控工具、剖析工具、调试工具。 2.数值理解：包括上面工具中所有输出的数据。 3.趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。 4.最后才是调优：有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。

性能分析思路大纲：

1. 瓶颈的精准判断
2. 线程递增的策略
3. 性能衰减的过程
4. 响应时间的拆分
5. 构建分析决策树
6. 场景的比对

瓶颈的精准判断：

递增压测过程，TPS的衰减过程大概会如下所示： 1.随着用户数的增加，响应时间也在缓慢增加。 2.TPS 前期一直都有增加，但是增加的幅度在变缓，直到变平。

所以对 TPS 曲线来说，它可以明确告诉我们的就是： 1.有没有瓶颈：其实准确说所有的系统都有性能瓶颈，只看我们在哪个量级在做性能测试了。 2.瓶颈和压力有没有关系：TPS 随着压力的变化而变化，那就是有关系。不管压力增不增加，TPS 都会出现曲线趋势问题，那就是无关。

响应时间是用来判断业务有多快的，而 TPS 才是用来判断容量有多大的。所以不一定是TPS越大就代表server端处理的事务的速度越快，只能代表量大

线程递增的策略：

对于场景中线程（有些工具中叫虚拟用户）递增的策略，我们要做到以下几点： 1.场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的 2.场景中的线程递增一定要和 TPS 的递增有比例关系，而不是突然达到最上限。后面在场景的篇幅中我们会再说它们之间的比例关系 3.上面两点针对的是常规的性能场景。对于秒杀类的场景，我们前期一定是做好了系统预热的工作的，在预热之后，线程突增产生的压力，也是在可处理范围的。这时，我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增，就是不合理的场景。

高老师场景递增的经验图如下：

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