性能：TPS和响应时间之间是什么关系

一张经典的图：

在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述：

• 三条曲线：吞吐量的曲线（紫色）、使用率/用户数曲线（绿色）、响应时间曲线（深蓝色）
• 三个区域：轻负载区（light load）、重负载区（heavy load）、塌陷区（buckle zone）
• 两个点：最优并发用户数（the optimum number of concurrent users）、最大并发用户数（the maximum number of concurrent users）
• 三个状态描述：资源饱和（resource saturated）、吞吐下降（throughput failing）、用户受影响（end users effected）

这是一张非常经典的示意图，描述了一个基本的状态。但是，示意图也只能用来做示意图，在具体的项目中，我们仍然需要有自己的判断

我们要知道，这个图中有一些地方可能与实际存在误差

• 首先，很多时候，重负载区的资源饱和，和TPS达到最大值之间都不是在同样的并发用户数之下的。比如说，当CPU资源使用率达到100%之后，随着压力的增加，队列慢慢变长，但是由于用户数增加的幅度会超过队列长度，所以TPS仍然会增加。也就是说资源使用率达到饱和之后还有一段时间TPS才会达到上限
• 大部分情况下，响应时间的曲线都不会像图中画的这样陡峭，并且也不一定是在塌陷区突然上升，更可能是在重负载区突然上升
• 另外，吞吐量曲线不一定会出现下降的情况，在有些控制较好的系统中会维持水平。
• 最优并发数这个点，通常只是一种感觉，并没有绝对的数据用来证明。在生成运维的过程中，一般不会将这个点设置为最优并发，而是更加靠前一点。
• 最大并发数这个点，就完全没有道理了，性能都已经衰减了，最大并发数肯定是在更前的位置啊。这里就涉及到一个误区，压力工具中的最大用户数或者线程数和TPS之间的关系。在具体的项目实施中，应该更关心服务端能处理的请求数即TPS，而不是压力工具中的线程数
• 这张图没有考虑到锁或者线程等配置不合理的场景，而这类场景有比较常见。也就是说我们说的，TPS上不去，资源用不上。所以这张图默认了一个前提，只要线程用得上，资源就能上涨

此图最早的出处是 2005 年 Quest Software 的一个 PSO Consultant 写的一个白皮书《Performance Testing Methodology》。在 18 页论述了这张图，原文摘录一段如下：

You can see that as user load increases, response time increases slowly and resource utilization increases almost linearly. This is because the more work you are asking your application to do, the more resources it needs. Once the resource utilization is close to 100 percent, however, an interesting thing happens – response degrades with an exponential curve. This point in the capacity assessment is referred to as the saturation point. The saturation point is the point where all performance criteria are abandoned and utter panic ensues. Your goal in performing a capacity assessment is to ensure that you know where this point is and that you will never reach it. You will tune the system or add
additional hardware well before this load occurs.

您可以看到，随着用户负载的增加，响应时间缓慢增加，而资源利用率几乎是线性增加的。这是因为您要求应用程序执行的工作越多，它需要的资源就越多。然而，一旦资源利用率接近100%，就会发生一件有趣的事情——响应呈指数曲线下降。这一点容量评估称为饱和点。饱和点是指所有的性能标准都被抛弃，完全的panic随之而来。执行能力评估的目的是确保你知道这个点在哪里，而且你永远也达不到它。您将在加载发生之前对系统进行优化或添加额外的硬件。

按照这段描述，这个人只是随着感觉在描述一种现象，除此无它。比如说，The saturation point is the point where all performance criteria are abandoned and utter panic ensues. 在我的工作经验中，其实在 saturation point 之前，性能指标就已经可以显示出问题了，并且已经非常 panic 了，而我们之所以接着再加压力是为了让指标显示得更为明显，以便做出正确的判断。而调优实际上是控制系统在饱和点之前，这里有一个水位的问题，控制容量达到什么样的水位才是性能测试和分析的目标

我们简化出另一个图形，以说明更直接一点的关系。如下所示：

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

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

在我的工作中，这样的逻辑关系更符合真实的场景。我不希望在这个关系中描述资源的情况，因为会让人感觉太乱了。

为什么要把上面描述得如此精细？这是有些人将第一张图中的 Light load 对应为性能测试，Heavy Load 对应为负载测试，Buckle Zone 对应为压力测试……还有很多的对应关系。

事实上，这是不合理的。

下面我将用场景的定义来替换这些混乱的概念。

为什么要如此划分？

• 因为在具体场景的操作层面，只有场景中的配置才是具体可操作的
• 而通常大家认为的性能测试、负载测试、压力测试在操作成名，只有压力工具中线程数的区别，其他的都在资源分析的层面，而分析在很多人的眼中，都不算测试。

拿配置测试和递增测试举例吧。

• 在性能中，我们有非常多的配置，像是JVM参数、OS参数、DB参数、网络参数、容器参数等等，如果我们把测试这些配置参数，称为“配置测试”，未免过于狭隘了。因为对于配置参数来说，这只是做一个简单的变更，而性能场景其实并没有任何变化。配置更改前后，会用同样的性能场景来判断效果，最多再增加一些前端的压力，实际的场景并没有任何变化。所以，它不配做为一个单独的分类。
• 再比如递增测试，在性能中，基准性能场景也好，容量性能场景也好，哪个是不需要递增的呢？我知道现在市场上经常有测试工程师，直接就上了几百几千线程做压力（请你不要告诉我这是个正常的场景，鉴于我的精神有限，承受不了这样的压力）。除了秒杀场景，同时上
  所有线程的场景，我还没有见到过。在一般的性能场景中，递增都是必不可少的过程。同时，递增的过程，也要是连续的，而不是 100 线程、200 线程、300 线程这样断开执行场景，这样是不合理的。关于这一点，我们将在很多地方着重强调。所以我觉得递增也不配做一个单独的分类。

其他的概念，就不一一批驳了。其实在性能测试中，在实际的项目实施中，我们并不需要这么多概念，这些杂七杂八的概念也并没有对性能测试领域的发展起到什么推进作用。要说云计算、AI、大数据这些概念，它们本身在引导着一个方向。

总结

总之，在具体的性能项目中，性能场景是一个非常核心的概念。因为它会包括压力发起策略，业务模型、监控模型、性能数据（性能中的数据，我一直都不把它称之为模型，因为在数据层面，测试并没有做过什么抽象的动作，只是使用）、软硬件环境、分析模型等