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准确。
当然待考证。如果谁知道还请指教。