【转】压力逐渐加大 tps下降，响应时间没有变化，系统资源不饱和，为什么？

性能测试过程中有很多不确定因素，未知的知识太多，很多时候看似很奇怪的现象其实有着合理的解释，看看下面这段对话吧

 

 

Carl:

压力逐渐加大 tps下降 响应时间没有变化

系统资源不饱和 为什么

浮生：

你们先不要吵 首先 响应时间 和吞吐率之间是没有关系的 一会我给你们具体原因

Carl 10:31:38

压力逐渐加大 tps下降 响应时间没有变化

系统资源不饱和 为什么

linkin 10:31:46

。。。

大叔 10:32:14

什么类型的系统

Carl 10:32:20

怎么都不说话了

Carl 10:32:24

linux

大叔 10:32:31

BS CS？

Carl 10:32:53

bs

linkin 10:33:19

大叔，你阿记得这个问题，我在胡凯他们群里教过的

月色江声 10:33:18

HPS怎么变化的？

大叔 10:33:43

真不懂这是啥原因

Carl 10:34:05

浮生 大神 说说

Carl 10:34:24

主要看你的分析问题的思路了

浮生 10:36:55

你们先不要吵 首先 响应时间 和吞吐率之间是没有关系的 一会我给你们具体原因

charmer 10:39:43

额，网络是不是瓶颈，好像没给出指标变化啊？

charmer 10:40:07

是不是随着压力的不断增加，也会增加？还是不变了？

charmer 10:40:42

遇到问题，只能拿数据出来一个一个的排查

Carl 10:40:45

记住响应时间没有变化

linkin 10:40:54

这是个陷阱

linkin 10:41:03

埋坑给你跳的

charmer 10:41:04

响应时间是没变化啊

linkin 10:41:25

响应时间和系统资源这2个条件，就限制了很多情况的发生

charmer 10:41:41

如果网络是瓶颈的话，到达后台的请求数没变化，后台处理的请求数没变化，你说响应时间会有变化吗？

charmer 10:41:48

恩，是的

Carl 10:42:28

如果网络堵了 你敢说响应时间没有变化？

charmer 10:42:27

前提是系统资源充足的情况

浮生 10:49:42

你们说完了么 ？

浮生 10:50:54

哦 那我说了 首先 吞吐量 是一个容器量 不是个速度两

浮生 10:52:11

我举个具体的例子 做个计算 你们就知道了

浮生 10:54:53

忽略初始化速度和思考时间的偏差 我们将一个request0的响应时间 设为0.4S 其他响应时间为0.2S 对于这个测试过程 可以这样描述 一个工作线程 执行request0 休眠2S 执行request1 休眠2S 等等 按照这个方式 45S后 request0 执行了3次 65S后 仍然是3次

 

独自等待 10:58:16

不明白

浮生 10:58:18

这样可以了解到每秒的请求书 后一种情况 我们得到的是 (3/65*500)= 23TPS 而对于非request0的请求 如果把它的响应时间 提高到0.4S 那么出现的计算记过 必然是TPS小于按照0.2S计算的结果

 

浮生 10:59:41

carl 你们总监想问的问题 不是这个系统是不是有瓶颈 而是 问的是TPS实际的计算方法

 

linkin 11:02:05

carl，你们总监想要的答案，就是浮生回答的吗？

lee 11:02:15

浮生讲得好好的。

Carl 11:02:45

3/65*500 这里是什么数据？

Carl 11:03:00

无解，我也不知道

独自等待 11:03:41

lee娘，你明白了？

浮生 11:03:57

哦 我初始设定的是500个并发 忘记说了

 

linkin 11:04:40

如果把它的响应时间 提高到0.4S 那么出现的计算记过 必然是TPS小于按照0.2S计算的结果

这句话

lee 11:05:06

500用户哈

lee 11:05:40

只是看懂了皮毛。

linkin 11:05:55

我艹，你还懂皮毛，我连皮毛都不懂

浮生 11:06:12

carl 去问问你那总监吧

浮生 11:06:21

就说你想到答案了

 

Carl 11:07:07

不敢

 

白の羽翼 11:07:59

要是负载的机器出现问题会有这样的现象出现吗？ 我就是随便想的。。。

 

Carl 11:10:40

浮生 你这个响应时间有变化了，导致的tps降低的

linkin 11:11:15

忽略初始化速度和思考时间的偏差 我们将一个request0的响应时间 设为0.4S 其他响应时间为0.2S 对于这个测试过程 可以这样描述 一个工作线程 执行request0 休眠2S 执行request1 休眠2S 等等 按照这个方式 45S后 request0 执行了3次 65S后 仍然是3次

为什么45S3次，65S还是3次，中间这20秒，线程干什么去了？

linkin 11:04:40 AM

如果把它的响应时间 提高到0.4S 那么出现的计算记过 必然是TPS小于按照0.2S计算的结果

这句话貌似和前文没什么因果关系

linkin 11:12:02

完全不懂浮生大神的意思，求解释~

白の羽翼 11:13:06

然后刚才Carl 的 技术总监问的问题 我想问一下啊 说的系统资源不饱和 说的能具体点吗？是APP还是DB？

白の羽翼 11:13:53

问题说具体点好 每个环节都要看的， 如果数据库出现瓶颈， 比如说有数据库锁， 那么从app看， 资源会释放出来的。

 

白の羽翼 11:14:51

所以资源监控会看到资源没有饱和

charmer 11:15:00

好好研究下大神们的解密算法

白の羽翼 11:15:31

Loadrunner本身出问题了也不一定

Carl 11:15:51

哪有那么多条件 就这么多，你给出分析问题思路

charmer 11:15:58

忽略初始化速度和思考时间的偏差 我们将一个request0的响应时间 设为0.4S 其他响应时间为0.2S 对于这个测试过程 可以这样描述 一个工作线程 执行request0 休眠2S 执行request1 休眠2S 等等 按照这个方式 45S后 request0 执行了3次 65S后 仍然是3次 这样可以了解到每秒的请求书 后一种情况 我们得到的是 (3/65*500)= 23TPS 而对于非request0的请求 如果把它的响应时间 提高到0.4S 那么出现的计算记过 必然是TPS小于按照0.2S计算的结果

 

charmer 11:16:13

好好研究下浮生的话

linkin 11:16:19

carl，浮生大神的思路，你理解了？

charmer 11:16:34

谁有研究出来的，提纲挈领下，我容易懂

charmer 11:16:47

浮生，你的依据是啥啊

linkin 11:16:56

举例举例

linkin 11:17:11

没依据的，自己揣摩去

Carl 11:17:31

我只能说他计算tps方法是对的，但是没有解决这个问题

linkin 11:17:44

我感觉没因果关系，而且是花费的时间来换取TPS的

linkin 11:17:52

与题目的意思有点违背了

charmer 11:17:53

一个工作线程 执行request0 休眠2S 执行request1 休眠2S 等等 按照这个方式 45S后 request0 执行了3次 65S后 仍然是3次

白の羽翼 11:17:58

Carl 我说的那些你看到了吗？

charmer 11:18:21

这个求解释

charmer 11:18:50

这个是假设的吗？

charmer 11:18:55

还是怎么得到的？

charmer 11:19:09

不是看好像你们很多人都懂了吗？

lee 11:21:07

浮生要表达的意思是 响应时间 和吞吐率之间没关系。

Carl 11:21:55

…

白の羽翼 11:17:58

Carl 我说的那些你看到了吗？

这是面试题，你能说你的测试机上的lr有问题导致的

charmer 11:22:15

为啥是休眠两秒？好，当假设吧，那为啥45s后执行了3次？是怎么计算的？

charmer 11:22:48

这个怎么计算的？

charmer 11:22:51

求解啊

charmer 11:23:08

小l

charmer 11:23:10

好像你懂了一样

charmer 11:23:15

告诉我

charmer 11:23:18

我不懂啊

lee 11:23:37

好吧，容我猜上一猜，

lee 11:24:00

其实这里面还缺少了一些假设。

charmer 11:24:19

把你的假设说出来，让我学习学习

lee 11:25:24

就是有多个request，假设有6~7歌这样的，那么45秒，request0只能执行3次，而65S也 是三次~~~

linkin 11:26:10

lee娘是浮生徒弟，应该能渗透大神的意思

lee 11:26:14

我瞎猜的~~~

lee 11:26:20

完毕。。

linkin 11:26:16

来，给我们宣导宣导

lee 11:26:49

讲完了，下面等浮生点评。

linkin 11:27:22

问题打住，大家自己猜去吧

lee 11:28:07

我是猜的，个人理解~~~

linkin 11:28:50

恭喜你，猜对了，+1分

 

lee 11:29:39

好吧，写文档去，我好像懂了一点点。。

浮生 11:29:38

我去 你们竟然还在理解 …… 服了 出去上了个厕所

 

lee 11:29:57

响应时间~~吞吐~~~

浮生 11:30:08

OK 再说条件 这个服务器 是单核的 那么 每次 只能处理一个线程的请求

 

golden 11:31:35

没有作为事务的请求响应时间长了........

浮生 11:32:26

有500个并发 那么 按照理想情况 0.4S处理一个请求 500个并发 处理完一轮 是20S

 

浮生 11:32:52

所以是3

 

浮生 11:33:08

这是理想的竞争模式 吃饭去了

 

浮生 11:33:10

所以 45S和65S 对于request0来说 是一样的 都只处理过了3轮

 

lee 11:33:58

我猜错了~~

linkin 11:34:13

猜错不扣分的

lee 11:35:14

还是写文档去

charmer 11:35:10

感觉说的太复杂了

charmer 11:36:13

简单的问题复杂化了，哎，看来只能继续潜心学习了

charmer 11:38:17

我想把浮生的话给他们总监，也会整糊涂的

linkin 11:38:32

 

linkin 11:38:35

不会

linkin 11:38:44

既然能做到总监，肯定有过人的本事

charmer 11:38:52

这个我知道

charmer 11:40:47

意思说你现在整明白了？

linkin 11:41:33

浮生把先前忘记的前提条件都加进去了，你还不明白？

charmer 11:41:33

理论上40s后，顺序执行的话，第二轮完毕了

charmer 11:41:48

为啥是45s？

linkin 11:41:52

他说的理想状态，是不存在的

golden 11:42:33

我觉得这个问题就是carl自己公司特定情况下出现并解决的吧 某些情况下一个索引也可以导致carl说的那个问题 一个字段类型定义的不同也可以 一个图片是否缓存都可以

linkin 11:43:12

这是个面试题，面的是解决问题和分析问题的思路

linkin 11:43:36

对口味的，就面上了，不对口味，就拜拜

linkin 11:43:42

就这么简单