响应时间（max & min）

[color=red][b]MAX Response time[/b][/color]
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。（问题依旧）


[img]http://dl2.iteye.com/upload/attachment/0110/7074/b01a2fcd-c4d8-3cf4-bc71-8ba17331207d.png[/img]

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


[img]http://dl2.iteye.com/upload/attachment/0110/7072/bd90faad-dce5-3c33-af23-fd82947bc352.png[/img]


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

[img]http://dl2.iteye.com/upload/attachment/0110/7195/0a9a3567-d047-324f-9895-ec2c1484d0f7.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0110/7197/a1fb5832-bb71-3c6b-ac3b-8963dae3757d.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0110/8057/f85090c9-45f6-3b0b-9e6e-16d41f63fe18.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0110/8059/3cbd55af-9d68-3aac-9a74-637a50d1766a.png[/img]

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

[img]http://dl2.iteye.com/upload/attachment/0110/8064/d88605bb-beb5-3041-b947-1c678358b5b4.png[/img]

[img]http://dl2.iteye.com/upload/attachment/0110/8069/8f8029a8-ca44-3ea0-b3d3-a4ffa681015d.png[/img]

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

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


[img]http://dl2.iteye.com/upload/attachment/0110/8080/33cabefc-1c3b-31d2-82e8-1f639da39075.png[/img]

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