2、TPS和响应时间之间的关系

学习性能的人，一定看吐过一张图，现在让你再吐一次。如下：

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

1、三条曲线：吞吐量的曲线（紫色）、使用率 / 用户数曲线（绿色）、响应时间曲线（深蓝色）。

2、三个区域：轻负载区（Light Load）、重负载区（Heavy Load）、塌陷区（Buckle Zone）。

3、两个点：最优并发用户数（The Optimum Number of Concurrent Users）、最大并发用户数（The Maximum Number of Concurrent Users）。

4、三个状态描述：资源饱和（Resource Saturated）、吞吐下降（Throughput Falling）、用户受影响（End Users Effected）。

在很多地方，都可以看到对这张图的引用。应该说，做为一个示意图，它真的非常经典，的确描述出了一个基本的状态。但是，示意图也只能用来做示意图，在具体的项目中，我们仍然要有自己明确的判断。

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

很多时候，在重负载区中，资源饱和和TPS达到最大值之间，并不是在同样的并发用户数之下的。比如说，当 CPU 资源使用率达到 100% 之后（资源饱和），随着压力的增加，队列慢慢变长，但是由于用户数增加的幅度会超过队列长度（服务器会接收访问，但是资源处理，然后就是请求超时），所以 TPS 仍然会增加，也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。

大部分情况下，响应时间的曲线都不会像图中画得这样陡峭，并且也不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。在重负载区这个过程中资源使用趋于上上并达到饱和，所以在此过程中，响应时间的曲线已经趋于向下。

另外，吞吐量曲线不一定会出现下降的情况，有些控制较好的系统在队列上处理得很好，会保持稳定的 TPS，然后多出来的请求都被友好拒绝。

最优并发数这个点，通常只是一种感觉，并没有绝对的数据用来证明。在生产运维的过程中，其实我们大部分人都会更为谨慎，不会定这个点为最优并发，而是更靠前一些。

最大并发数这个点，就完全没有道理了，性能都已经衰减了（TPS下降，响应时间增长），最大并发数肯定是在更前的位置呀。

这里就涉及到了一个误区，压力工具中的最大用户数或线程数和 TPS 之间的关系。在具体的项目实施中，有经验的性能测试人员，都会更关心服务端能处理的请求数即 TPS，而不是压力工具中的线程数。这张图没有考虑到锁（线程锁阻止线程并发，多核CPU也只能使用1核）或线程等配置不合理的场景，而这类场景又比较常见。也就是我们说的，TPS 上不去，资源用不上。

所以这个图默认了一个前提，只要线程能用得上，资源就会蹭蹭往上涨。这张图呢，本来只是一个示意，用以说明一些关系。但是后来在性能行业中，有很多没有完全理解此图的人将它做为很有道理的“典范”给一些人讲，从而引起了越来越多的误解。

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

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

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

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