响应时间（max & min）

MAX Response time
java脚本，ssf接口
A系统面向用户展示，B系统是外围系统。
A系统要求B的响应在500ms以内。如果超过500ms则算超时，计入error日志。

根据日志捞了两次错误日志，根据压力不同，超时个数为
大压力 超时大约100:1
小压力 超时大约2500:1

B系统铺底数据1亿，B系统应用和DB排查，DB耗时稳定且无超时，SQL是一个简单查询。


分析：
1.开发使用工具检查每个类的用时。
2.检查是否存在full gc。（检查gc日志）
3.垃圾回收策略配置。
4.JVM的参数设置检查。
5.开发将响应消息直接返回null。（问题依旧）





发现：
1.发现问题后反复测试，清过本系统日志，清过相关系统日志如会员，就是没清过问题系统日志，df检查时该系统日志目录始终无较空闲。





解决：
开发做了定期日志打包动作，所以发现超时都是阶段性的。
去除打包动作，超时现象解决了，但性能下降了10倍。
且增加压力的话，tps无变化，响应时间依旧出现超时。



解决：
开发调整了日志级别。tps和响应时间恢复。



MIN Response time
铺底数据1亿，TPS:4000，RS:9ms
这么大的数据量，这么好的响应时间，是我测试以来性能最好的一个接口了。
开始怀疑自己测试的准确性。
分析：
1.loadrunner工具统计的不准确
2.是否因为缓存
解决：
1.loadrunner单调BI系统，场景执行展示的平均响应时间。
  开发日志，外部调用调用BI系统，从请求发出到接受到BI响应所用的时间。
 




  从工具和开发的日志看出，真的是消耗了这么多时间。
2.调用捞取一匹未使用过的数据，且不从库里面捞。
  组网：双机+DB（主备）无redis服务器
  结果比对。
  使用过的数据（可能有缓存）Average Time：9ms，
  无缓存数据                Average Time：15ms。
  准备了30w，数据用一个用户去压测。想低tps多跑会，免去缓存问题。
 




   可能存在缓存问题，但是时间差很小6ms。

3.开发加BI系统的DB调用日志
  查询的是多次使用的数据，BI的DB响应时间都在2ms。
  1亿条数据，表字段10来个，在建了唯一索引的情况下，速度就是杠杠的。




待解决：
为什么用db查询工具查出来的数据比load测试（应用+查DB）出来的时间还长。
我的理解：1.场景本身耗时就很小
          2.db工具只强调结果正确性，响应时间不一定有load准确。
当然待考证。如果谁知道还请指教。