大叔 9:56:06
TPS 可以下降，俺就不相信响应时间不升高
大叔 9:56:23
万物阴阳结合一高就一低
大叔 9:56:35
不可能顾此失彼的
Jack 9:56:54
没明白
乖乖 9:56:58
会不会有其他的因素呢？
Carl 9:57:25
泊涯 如果是前端集群端口慢了会不会出现这种情况
大叔 9:57:49
你压力测试时间多久
Jack 9:57:50
算法都没明白，不知道咋就20S了
大叔 9:58:01
端口慢了， 你是不是会堵塞
Carl 9:58:06
比如F5 2000连接满了
大叔 9:58:12
堵塞久了是不是响应时间就大了
上风 9:58:16
堵塞了 响应时间肯定也要下来
大叔 9:58:25
是上去了 不是下来了
上风 9:58:33
后面的请求就会等待。。等待响应时间必然增加
Jack 9:58:35
对啊
大叔 9:58:46
TPS下降短时间内最大可能就是客户端有设置缓存
大叔 9:59:02
所以导致 客户端没跟服务器打交道直接在缓存取数
大叔 9:59:16
所以短时间内看不出响应时间变化
Carl 9:59:36
还有一种可能性，就是异步提交请求，这有可能吗？
大叔 9:59:41
这个可以用httpwatch 看得出来 IE会去监控是否修改版本
大叔 10:00:12
你的异步只能是类似ajax 这种可以临时缓存的才会
大叔 10:00:16
而且是BS架构的
linkin 10:00:26
大叔
大叔 10:00:37
你啥观点
linkin 10:00:40
他们题目说响应时间没有变
linkin 10:00:55
其实严格意义来讲，还是会发送微量变化的
linkin 10:01:07
我们平时看到的只是平均值而已
大叔 10:01:13
我是觉得有变化，所以在阐述观点 导致不变的架构体系应该是哪些
linkin 10:01:29
其实，某些userid还是会忽高忽低的
linkin 10:01:53
因为平均值没怎么变，所以大家就定性的认为不变了
大叔 10:02:01
嗯 肯定是有变化的
异步上出现的不变问题我还是没接触过
linkin 10:02:24
至于什么类型的，上次在胡凯群里，我不是讨论过了嘛
linkin 10:02:42
压力变大了，TPS是有可能下降的，响应时间不变
linkin 10:02:52
这个问题，我们很早之前就讨论过了
linkin 10:03:05
出发点是：压力增加这个词
linkin 10:03:13
如果增加压力，很有学问的
charmer 10:03:28
异步，在那里异步？
charmer 10:03:37
异步对服务器的压力更大啊
charmer 10:03:44
资源都没满
大叔 10:03:59
应该是指应用层的异步
大叔 10:04:05
客户端的
大叔 10:04:15
如果是服务端的 我是觉得消耗的资源更大
charmer 10:04:26
我们现在的系统就是做成前置机到后台中央系统的异步
charmer 10:04:43
到了前置机后就直接往后台丢
charmer 10:04:48
是啊
charmer 10:05:00
而资源没满负荷
大叔 10:05:22
那你觉得这样会导致响应时间不变，TPS下降不？
charmer 10:06:19
想了很长时间都没想明白这是为啥
Carl 10:06:24
这样前端只管丢 响应时间变化应该不大
Carl 10:06:49
在逐渐加压后tps有可能下降
大叔 10:06:53
但是这是短时现象啊
大叔 10:07:09
我就是想不明白
大叔 10:07:39
最多就是类似ajax这种框架的，如carl说的前端丢了，不管回应
大叔 10:07:55
但是时间久了 前端一直并发后台来不急处理肯定导致出问题
linkin 10:08:04
这个问题比较大，前提条件也比较多
大叔 10:08:14
除非场景设置为 100个并发 100个请求就完成测试
大叔 10:08:21
这种可能会
linkin 10:08:21
具体问题，具体分析的好
charmer 10:08:41
但是资源不满负荷，随着压力的增大，资源肯定会满负荷。。。
大叔 10:08:45
但是如果大批量请求很多时，运行时间很长的情况下，还是会有问题
大叔 10:09:01
响应时间还是会增加
charmer 10:09:05
如果看短暂时间的话，那就没法看了
大叔 10:09:06
tps还是下降
大叔 10:09:09
嗯
大叔 10:09:24
得看测试时间场景怎么发分了
charmer 10:09:35
恩
大叔 10:09:51
或者说你的服务器很强悍
大叔 10:10:00
但是网口受限是短暂的
大叔 10:11:28
carl 你说下你的看法，问题是你抛出来的
Carl 10:12:04
我已经说了，我这没答案
charmer 10:12:13
是啊，给大家点提示，大家都发表下讨论，共同学习吗
Carl 10:12:20
我感觉就是考察分析问题的思路的
charmer 10:12:27
不是说要你答案，而是发表你的看法
Carl 10:12:36
给出几种可能
linkin 10:13:10
给吧
Carl 10:13:52
1、集群服务器是瓶颈
2、请求异步提交
kevin 10:14:52
客户现场那边系统反应慢要如何处理
大叔 10:16:22
不宕机就不管
kevin 10:17:02
但必须得解决，系统反应慢他们没法工作
大叔 10:17:02
查看服务器资源哪里是瓶颈进行，分析问题，然后测试环境进行优化测试，在打补丁 这个是针对代码之类问题的
大叔 10:17:18
如果是其他的问题，这个只能现场查看了
kevin 10:17:52
就是这个测试，我是在客户那边做，还是测试环境
linkin 10:18:01
carl，集群服务器是瓶颈，你的响应时间是server的响应时间不变，还是从客户端-server端-在到客户端整个时间不变啊？
Carl 10:18:46
我们通常怎么理解响应时间？
linkin 10:19:03
那你集群是瓶颈，响应时间会不变？
linkin 10:19:34
按照你的说法，线程满了，后起的会处于堵塞或者等待状态，响应时间会不增加？
Carl 10:20:13
这样server的处理时间会快了
Carl 10:20:50
平均响应时间会没有变化
linkin 10:21:25
server怎么会变快，server处理一个request的时间理想状况下，应该是不变的
linkin 10:21:43
不管你是单核的还是多核的
Carl 10:21:47
三千请求 集群跳转了2000 一千排队
业务层服务不饱和
linkin 10:22:15
server端处理的时间是不变的啊
golden 10:22:22
在
linkin 10:22:34
只会增加，不会减少的
linkin 10:23:04
。。。
浮生 10:23:07
你们还在讨论昨天的问题 ？
Carl 10:23:36
恩
上风 10:24:01
没理解明白
浮生 10:24:10
额 小号昨天说的 肯定不对 加了缓存后 响应时间会下降 但是吞吐量会上升
golden 10:24:46
我擦 你说反了吧？
浮生 10:24:59
我擦 大哥 我亲自做过
浮生 10:25:28
你把缓存使用上 吞吐率按request/S来算 绝对是变大的
浮生 10:27:06
响应时间变小
linkin 10:27:39
浮生，他们说集群瓶颈会造成这样的影响，你怎么看？
linkin 10:27:45
我个人不同意这么一说法
浮生 10:27:47
不可能
linkin 10:27:52
听听你的看法
linkin 10:28:56
如果是异步的话，你的响应时间又怎么得出呢？
浮生 10:30:27
如果你的响应时间 是从服务器得到的 那这种情况有可能 不管是同步还是异步 响应时间 只能是客户体验时间
linkin 10:31:07
他说的响应时间，不是S端的
linkin 10:31:24
所以我就奇了怪了
浮生 10:37:29
其实 carl说的 不能代表普遍情况 确实有这种情况 比如提交数据的异步处理的请求 或许可以 我做过的很多JMS的项目 可能是这么处理的
浮生 10:38:22
但是 响应时间不变 吞吐量不变 作为一种特例 出来作为面试题 很不妥 但是 理解吞吐量的计算方法 是可以做出回答的
golden 10:40:20
我说的是图片缓存 不过如果你们理解的响应时间是用户体验 不是lr测试的那个 那么我就错了
浮生 10:41:55
这个有 如果你把图片缓存去掉 吞吐量会减少 但是响应时间会变大
golden 10:43:18
不是绝对的 可以做到响应时间不变 但是tps减少
浮生 10:44:07
我觉得 这种测试 说明不了问题 如果缓存去掉和没去掉 起的作用是一样的话
golden 10:45:29
所以我说是特定情况下出现的问题 carl提出来的那个问题现象本来就是很奇怪的
浮生 10:45:44
但是我觉得可以解释 也可以被理解
浮生 10:45:55
如果就一个个例来说 没什么意义
linkin 10:49:11
总监提的问题，肯定要诡异
浮生 10:51:13
总监 如果不能从个案中 整理出来一个普遍的规律 就不配做总监 要不 carl 约下你的总监 我们话聊下？
linkin 10:52:20
我感觉，这个问题，还是比较有深度的，不是那么容易见到的
浮生 10:53:05
我遇到过2次 都是在JMS测试中遇到的
linkin 10:53:26
我遇到过一次
Carl 10:53:41
我也遇到过，没有定位到问题
浮生 10:53:42
我总结出来的 就是响应时间 和吞吐量之间 没什么必然联系
linkin 10:54:22
我遇到的那次，现象比较明显，换了种测试模型，TPS20%左右的降幅
linkin 10:54:33
响应时间和服务器资源没什么变化
浮生 10:54:55
你们说的 不是carl昨天的问题的复现
linkin 10:55:14
的确不是，只不过有点类似
linkin 10:55:38
用马路原理一解释，就通了
乖乖 10:56:06
马路原理？
浮生 10:56:10
carl说的 是在同一个测试场景下
linkin 10:56:36
我也是同一场景下
linkin 10:56:45
只不过，我的加压手段不一样而已
浮生 10:57:15
加压手段都不一样了 还叫一个测试场景 ？？
linkin 10:58:16
目标是一样的啊
linkin 10:58:24
面向对象场景
浮生 10:59:39
大哥 测试场景 中最重要的一条 就是加压方式 ……
linkin 11:00:16
其实我最近在研究这个
linkin 11:00:20
但是没什么好的思路
linkin 11:00:26
浮生，你有什么好的建议吗？
linkin 11:01:06
如果系统稳定，当你的目标到达后，应该会趋于稳定运行的
浮生 11:01:25
稳定的一个前提 是吞吐量稳定 ……
linkin 11:01:34
但是很多系统，不是这个样子的，你的加压方式不一致，会导致最后的测试结果也会发生翻天覆地的变化
linkin 11:01:42
对，吞吐量就是稳定
linkin 11:02:22
遇到这样的情况，我在想，是不是他的内存使用上有点问题
浮生 11:02:25
这要你去分析
linkin 11:02:31
对啊
linkin 11:02:57
但是系统不一样，结果都不一样，我需要搞套自己的东西出来