聊聊连续、递增

1 引子

在性能工程中，想要明确知道当前业务在现有的生产环境，最高支撑的流量上限水平，就需要我们做如下几项工作：基准工程，容量工程，稳定工程，异常工程； 其中基础工程在整个事项工程是最基本的且为必须要做的节点工作，因为在基准工程中，找到系统的BUG,系统配置缺陷，系统性能相关问题是核心目的之一，同时也为容量场景提供可对比的基准数据；

2 连续、递增

在生产环境里业务的访问没有不连续的情况，并且生产环境中，用户量肯定是一个由少到多、有起伏变化的过程，在连续的过程中，用户量的递增也是由少到多，那么在整个性能过程中，只有连续，递增这能把场景的基调给定下来。

2.1 基准场景–连续、递增

在我们对一个系统完全不了解的情况下，我们先要搞清楚系统大概的容量能力是多少，具体要从哪里开始？就是从基准场景开始，比如说在这一个电商系统中，要测试 11 个业务，那是不是可以一上来就把这 11 个业务脚本都做出来，上去压呢？那肯定是不行的，因为我们还不知道每一个业务能跑到多大的 TPS，有没有性能瓶颈。如果直接混合去压，会导致多个性能问题一起暴露出来并产生相互的影响，这样的话我们分析起来会比较困难。所以，要先做单接口的基准场景，那具体怎么做？看一个具体例子，首先，拿几个用户测试一下登录接口的基本性能（PS：这个尝试的过程本身并不是基准场景），如下所示：

从图中，我们至少可以看出，1 个压力线程大概会产生 20TPS，那单接口的容量达到多少才不影响混合的容量场景呢？很显然，如果这是一个单登录接口，就必须高过 50TPS，这是最起码的。而现在用的是 8C16G 的机器，根据 CRUD 的测试经验，即使不走缓存，这样的操作要达到 500TPS 应该没什么问题，那在一个线程能产生 20 个 TPS 的前提下，我们先假设这个接口能达到的最大 500TPS 都是线性的，那就需要：线程数=500TPS÷20TPS=25个线程同时，因为 1 个压力线程大概会产生 20TPS，从 TPS 曲线上看还是上升的比较快的，所以我会考虑把 Duration（场景的持续时间）放长一点，目的是让压力不要增加得太快，而在这个缓慢增加的过程中观察各类曲线的变化，以判断后续的动作以及最大容量，在后续的各种压测过程中，在后续的压测场景中基本上都会以连续，递增来确定场景的加压过程。

在图中，我上到了 30 个线程，这里也可以不要高出那么多，只要高出 25 个线程就可以了，把 Ramp-up period 设置为 600 秒，也就是 20 秒上一个线程，这样就会产生一个明显的连续递增的过程。

整体思路：
● 先确定单线程运行时的 TPS 值；
● 根据系统最大的预估容量设置场景中的线程数、递增参数等，强调一下，如果你不会预估容量，可以直接多加一些线程，然后在递增的过程中查看曲线的变化；
● 确定正式基准场景的压力参数。

对于其他接口，也用这样的思路一个个执行下去。当然，对于这个过程，我们也需要在测试过程中不断地修正，现在，我们根据上面讲述的过程，总结一下基准场景的目的：
● 获得单接口最大 TPS：如果单接口最大 TPS 没有超过容量场景中的要求，那就必须要调优。那如果超过了，是不是就不需要调优了呢？我们接着看第二个目的：

● 解决单接口基准场景中遇到的性能问题：也就是说，在做单接口测试时，碰到了性能瓶颈一定要分析，这就涉及到了性能分析逻辑。所以，性能分析基本上可以分为两大阶段：

第一阶段：硬件资源用完。即在基准场景中，我们要把 CPU、内存、网络、IO 等资源中的任一个耗尽，因为在这种情况下，我们很容易从全局监控的性能计数器中看到现象，可以接着去跟踪分析。*

*第二阶段：优化到最高 TPS。即在基准场景中，我们要把单接口的 TPS 调到最高，以免成为容量场景中的瓶颈点。

• 如果第一阶段的目标达不到，那么不用多想，必须要找瓶颈在哪里。要是硬件资源已经用完了，TPS 也满足了容量场景中的要求，那么，从成本的角度来考虑，这个项目就不需要再进行下去了。如果硬件资源用完了，但 TPS 没有满足容量场景中的要求，那就必须优化。

• 可以用一个登录接口先来执行一个单接口场景，看一下上面的思路如何落地的。
  登录接口按照上面所讲的基准场景的设计步骤，我们先试运行一下这个接口的基准场景。注意，在基准测试中，试运行的过程只是为了看一下基本的接口响应时间，并不是为了完成基准场景。
  
  从图中看，虽然场景执行时间并不长，但是 10 个线程上来就报了错，响应时间和 TPS 都不正常，只有 12.5TPS。这可怎么办？

问题现象
从上述图可知：用户登录的响应时间过长；TPS过低

• 分析过程
  a) 折分时间，根据arm监控找到折分时间，找到响应时间慢的节点
  b) 通过arths跟踪代码执行的链路

• 连续性（Continuity）
  连续性要求在加压过程中，线程数或并发数的增加是连续的，而不是跳跃式的。例如，不应从100线程直接跳到300线程，而应是逐步、连续地增加。这种连续性有助于更准确地模拟真实用户行为，并且能够更精确地捕捉系统的性能变化

• 递增性（Incremental）
  递增性强调在加压过程中，应逐步增加并发数或负载，以观察系统的响应变化。通过逐步增加负载，可以更准确地识别系统的性能拐点（如TPS和响应时间的变化）。例如，从小流量逐步升压，观察系统响应变化，并记录TPS和响应时间，寻找拐点

• 实施策略
  ● 从小流量逐步升压：从较低的并发数开始，逐步增加并发数，观察系统的响应变化。
  ● 观察系统响应：在加压过程中，持续监控系统的响应时间、错误率、资源使用情况等指标，以识别性能瓶颈。
  ● 记录数据：记录每个阶段的并发数、TPS和响应时间，以便分析系统的性能趋势。

• 重要性
  连续和递增的加压策略不仅有助于更准确地模拟真实用户行为，还能更有效地识别系统的性能瓶颈和优化点。通过这种方式，性能测试不仅能够评估系统的最大承载能力，还能为系统的优化提供数据支持。
  通过遵循连续和递增的加压策略，性能测试能够更准确地评估系统的性能表现，为系统的优化和改进提供有力支持