【book】TPS和响应时间关系

1 关键词概念

吞吐量：是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。

响应时间：在网络上，指从空载到负载发生一个步进值的变化时，传感器的响应时间。

2 图例1

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

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

• 三个区域：轻负载区（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）。

实际也会和图中存在误差
1）很多时候，重负载去的资源饱和，和TPS达到最大值之间都不是在同样的并发用户数之下的。比如说，当CPU资源使用率达到100%之后，随着压力的增加，队列慢慢变长，但是由于用户数增加的幅度会超过队列长度，所以TPS仍然会增加，也就是说资源使用率到饱和之后还有一段时间TPS才会达到上限。

2）大部分情况下，响应时间都不一定是在塌陷区突然上升，更可能的是在重负载区突然上升。

3）吞吐量曲线不一定会出现下降的情况，有些控制较好的系统中会维持水平。曾经在一个项目中，因为TPS维持水平，并且用户数和响应时间一直都在增加，由于响应时间太快，一直没有超时。

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

5）最大并发数，性能都已经衰减了，最大并发数肯定是在更前的位。这里会涉及到一个误区，压力工具中的最大用户数或线程数和TPS之间的关系。在具体的项目实施中，有经验的性能测试人员，都会关心服务端处理的请求数即TPS，而不是压力工具中的线程数。

6）这张图没有考虑到锁或线程等配置不合理的场景，这类场景比较常见。也就是，TPS上不去，资源用不上。所以这个图默认了一个前提，只要线程能用得上，资源就能往上涨。

3 图例2

这里还有另外一张图

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

3）最后响应时间过程，达到的超时的程度。
4）场景定义替换这些混乱的概念

3.1 配置测试、递增测试

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

1）配置测试
性能中，我们有JVM参数、OS参数、DB参数、网络参数、容器参数等。这些进行配置参数，只是做一个简单的变更，性能场景没有任何变化。配置更改前后，会用同样的性能场景来判断效果，最多再增加一些前端的压力。实际的场景没有任何变化。

2）递增测试
在性能中，基准性能场景也好，容量性能也好，都是需要递增的，在一般的性能场景中，递增都是必不可少的过程。同时递增的过程是连续的

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

记录学习知识点分享