记一次性能分析

公司首页有个展示列表的接口，我也曾参与过其中部分方法的编写，反应时间很慢大约有3-4s，因为无从下手优化，请教D哥，D哥将代码重写将代码的运行时间减少到了0.6s左右，但是D哥也说不清原来代码为什么这么慢，于是我就对原来的代码和改进的代码进行了粗略分析。

在分析代码运行时间的工具上，看了网上各种各样的性能分析的工具，也试用了JProfiler，但是感觉过于底层分析，不是我想要的，选择了Spring提供的StopWatch类来进行断点记录对应时间，简单粗暴，符合我的需求。

 

原来的接口，平均耗时3.7s，大致步骤抽象如下。

1. 新建集合，查询出A

2. 新建集合，查询出B

3. 新建集合，查询出C

3. 新建集合，进行一个封装的多查询（D）

4. 排序

5. 新建集合，过滤筛选（E）

6. 手动分页得到F

 

使用Stopwatch后分析报告如下

ms    %  taskName

00005 000% 开始执行方法

00259 007% 查询A

00072 002% 查询B

00001 000% 查询C

02755 073% 封装多查询 D

00000 000% 排序

00705 019% 过滤  E  （for循环调用数据库并做筛选）

00000 000% 手动分页得到F

 

这里我们看到D步骤和E步骤占用了92%的时间，问题就出现在这两个步骤上，而D很明显是大头.

于是对D内部再进行分析

 

ms    %  taskName

00118 005% D1

02427 093% D2 (for循环里调数据库查询486次  486*0.005 =2.43s)

00059 002% D3

00000 000% D4

 

所以主要问题就出现在D2和E上面

 

下面我们再对新接口做分析，大致步骤如下 （与上面的ABCDEF并不完全一样）

1. 新建集合 A

2. 筛选 B in （A）

2. 筛选 C in （B）

3. 集合 D in （B，C）

4. 分页，由D得到E，进行封装多查询，得到F

 

综上

原始接口进行各种筛选和处理后,最后分页.

新接口先获得筛选后的集合,然后再分页查询(10条),再处理,少了几百次调数据库。.

 

优化分析

1. 原始的逻辑总体上属于按顺序进行,a-b-c,每次数据会筛选减少,所以没法分页.

而改进的则是倒过来先获得条件b,c 然后a in (b,c),这样可以就可以进行分页,减少数据处理量.

 

2. 原始接口的大约80%时间用于for循环调用数据库进行判断.

而在改进中, 对于20%（E步骤）的优化,是一次查询先取出所有符合条件的对象集合b,作为后面的判断条件，使得a in(b)

对于60%（D2步骤）的优化,则是先进行了分页,使得数据量从486条变为10条,再进行for循环调用数据库就不会占用太多时间了。

 

其他可能的优化点

1.流的使用