TPS和RT之间永远说不清楚的关系

lsekfe

引言
　　在开始今天的内容讲解之前，我们应该回顾一下，在我的全链路压测专栏中的第一篇，我就已经介绍了当前的性能测试在互联网企业中的重要性，已经性能在互联网行业中的占比是多少。
　　这个时候是不是会有同学问我， 你已经写过全链路压测的专栏，为什么还要写这个性能专栏呢？难道性能专栏和全链路压测专栏没有公用的地方吗？答案是肯定的。
　　性能工程与全链路压测工程之间的共同点很明确，就是压测；而区别点也明显，即线上/线下、生产数据/测试数据。
　　看到这里，是不是还有同学有疑问，既然有区别，那就把区别列出来好了，干嘛还要专门整一个专栏来写性能工程的文章呢？这次写出来的内容，会不会有重复的地方呢？
　　这一点需要你放心，我既然写性能工程专栏的内容，肯定是不会跟全链路压测专栏有重复。
　　全链路压测，是通过真实生产环境的数据进行改造，云服务器搭建；
　　性能工程，是通过物理服务器的搭建，使用的是非生产环境的数据。
　　说了这么多，我们就言归正传，来聊一聊性能测试中，TPS和RT之间的关系。
　　我想但凡了解或者做过性能测试的同学，都知道TPS与RT。但是，TPS和RT之间的关系，可能没有几个人能说清楚。或者说专职从事性能测试7年以下的同学，很少会完全理解(掌握)TPS和RT之间的关系，已经如何根据TPS与RT之间的关系，来判断系统的瓶颈点。
　　TPS与RT
　　我先上一张图，这张图，学习性能测试的同学，估计印象深刻。

在这个图中，定义了三条曲线、三个区域、两个点以及三个状态描述。
　　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 上不去，资源用不上。所以这个图默认了一个前提，只要线程能用得上，资源就会蹭蹭往上涨。这张图呢，本来只是一个示意，用以说明一些关系。但是后来在性能行业中，有很多没有完全理解此图的人将它做为很有道理的“典范”给一些人讲，从而引起了越来越多的误解。
　　在我的工作经验中，其实在 saturation point 之前，性能指标就已经可以显示出问题了，并且已经非常 panic 了，而我们之所以接着再加压力是为了让指标显示得更为明显，以便做出正确的判断。而调优实际上是控制系统在饱和点之前，这里有一个水位的问题，控制容量到什么样的水位才是性能测试与分析的目标。