在这个图中,定义了三条曲线、三个区域、两个点以及三个状态描述。
三条曲线:吞吐量的曲线(紫色)、使用率 / 用户数曲线(绿色)、响应时间曲线(深蓝色)。三个区域:轻负载区(Light Load)、重负载区(Heavy Load)、塌陷区(Buckle Zone)。两个点:最优并发用户数(The Optimum Number of Concurrent Users)、最大并发用户数(The Maximum Number of Concurrent Users)。三个状态描述:资源饱和(Resource Saturated)、吞吐下降(Throughput Falling)、用户受影响(End Users Effected)。
我们要知道,这个图中有一些地方可能与实际存在误差。
首先,很多时候,重负载区的资源饱和,和 TPS 达到最大值之间都不是在同样的并发用户数之下的。比如说,当 CPU 资源使用率达到 100% 之后,随着压力的增加,队列慢慢变长,但是由于用户数增加的幅度会超过队列长度,所以 TPS 仍然会增加,也就是说资源使用率达到饱和之后还有一段时间 TPS 才会达到上限。
大部分情况下,响应时间的曲线都不会像图中画得这样陡峭,并且也不一定是在塌陷区突然上升,更可能的是在重负载区突然上升。
最优并发数这个点,通常只是一种感觉,并没有绝对的数据用来证明。在生产运维的过程中,其实我们大部分人都会更为谨慎,不会定这个点为最优并发,而是更靠前一些。
最大并发数这个点,就完全没有道理了,性能都已经衰减了,最大并发数肯定是在更前的位置呀。这里就涉及到了一个误区,压力工具中的最大用户数或线程数和 TPS 之间的关系。在具体的项目实施中,有经验的性能测试人员,都会更关心服务端能处理的请求数即 TPS,而不是压力工具中的线程数。
这张图没有考虑到锁或线程等配置不合理的场景,而这类场景又比较常见。也就是我们说的,TPS 上不去,资源用不上。所以这个图默认了一个前提,只要线程能用得上,资源就会蹭蹭往上涨。
在我的工作经验中,其实在 saturation point 之前,性能指标就已经可以显示出问题了,并且已经非常 panic 了,而我们之所以接着再加压力是为了让指标显示得更为明显,以便做出正确的判断。而调优实际上是控制系统在饱和点之前,这里有一个水位的问题,控制容量到什么样的水位才是性能测试与分析的目标。
总结:
总之,在具体的性能项目中,性能场景是一个非常核心的概念。因为它会包括压力发起策略、业务模型、监控模型、性能数据(性能中的数据,我一直都不把它称之为模型,因为在数据层面,测试并没有做过什么抽象的动作,只是使用)、软硬件环境、分析模型等。