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
就这么简单