上次做了几个优化之后,发现系统当中如果有800个BUG的时候,显示测试报告详细信息的那个页面还是比较慢,大约要18s,实在是难于忍受。
虽说显示这个页面需要做很多的统计查询。但是,我已经对统计查询做过优化优化了,怎么还会花费这么长时间呢?拿出具体的数据看看是解决问题的最好方法,看具体那个方法执行得比较耗时。
结果出来,几个我认为比较耗时的数据库查询,其实根本就不耗时啊……一个是90ms,其它三个都低于50ms,也就是说页面显示这么慢,根本不是数据库查询的结果,瓶颈应该在其它地方。
拿到显示这个页面的Action一看,有一段代码看不懂了。在这个页面上没有必要做转换列表的操作啊,于是怀疑是否这个ACTION是否做了多余的操作。再查看JSP,如果没有用到Action当中设置的属性。因此,断定那段代码是多余的。
怎么会产生这段多余代码呢,肯定是因为在修改代码的过程中,程序员忘记删除这段耗时的代码了。
修改之后一看,18s -> 0.8s。真是太好了。问题解决了,一切OK。
这个问题说明三点:
1. 不要怀疑数据库的性能。
2. 一定要实际去测试一下,不要妄加猜测。
3. 写程序的时候,代码结构要清楚。
虽说显示这个页面需要做很多的统计查询。但是,我已经对统计查询做过优化优化了,怎么还会花费这么长时间呢?拿出具体的数据看看是解决问题的最好方法,看具体那个方法执行得比较耗时。
结果出来,几个我认为比较耗时的数据库查询,其实根本就不耗时啊……一个是90ms,其它三个都低于50ms,也就是说页面显示这么慢,根本不是数据库查询的结果,瓶颈应该在其它地方。
拿到显示这个页面的Action一看,有一段代码看不懂了。在这个页面上没有必要做转换列表的操作啊,于是怀疑是否这个ACTION是否做了多余的操作。再查看JSP,如果没有用到Action当中设置的属性。因此,断定那段代码是多余的。
怎么会产生这段多余代码呢,肯定是因为在修改代码的过程中,程序员忘记删除这段耗时的代码了。
修改之后一看,18s -> 0.8s。真是太好了。问题解决了,一切OK。
这个问题说明三点:
1. 不要怀疑数据库的性能。
2. 一定要实际去测试一下,不要妄加猜测。
3. 写程序的时候,代码结构要清楚。