MIS性能优化常见问题与方案（辅助项目组性能优化的总结贴）

最近帮忙公司的几个项目组进行了不一样方面的性能优化，发现几个项目都出现了一些共性的问题。这里写一篇文章，总结一下这几类问题，以及其对应的解决方案。方便其它项目组参考。

 

常见问题一：打开页面很是慢，有的项目打开一个页面居然要 20 多秒。

---

优化步骤：

1. 下降每个页面的请求数：使用浏览器跟踪打开页面后全部的请求，并逐一排查，把没有必要向服务端发起的请求优化掉，减小 Round Trip 次数。
2. 针对每个请求进行优化：对请求逐一排查，看看分别是哪些请求占用了较多的时间。
   若是该请求是 JS 文件，则考虑使用压缩版本（例如正在使用的 EXTJS，应该使用 ext-all.js 1.9M，而不是 ext-all-debug.js 4.5M）。
   静态资源要尽可能启用缓存。
3. 将每次请求所对应的数据库访问次数下降到最低：这一步属于后端优化。
   每个请求到达服务端后，都会作一系列的操做，例如：初始化当前用户、角色、权限、当前模块、业务逻辑、日志等。
   对于前四个操做，每每是全部页面都须要初始化的，那么咱们须要使用 Session 或 Cache 等技术来优化，以防止每次请求都从新访问数据库。
   对于业务逻辑、日志等，咱们主要解决的是《ORM 中的 N+1 问题》、优化掉多余的数据库访问（须要记住，每一次数据库访问，其实都是一次远程访问）。
4. 另外，Web 页面的前端优化，还能够参考《 YAHOO Web 优化的 14 条法则》。

 

常见问题二：单条 SQL 语句执行较慢

---

在数据量较大的状况下，一些 SQL 语句执行得很是慢。

优化步骤：

1. 是否 SQL 自己有性能问题？
2. 是否创建了表分区？
   http://www.cnblogs.com/leiOOlei/archive/2012/06/08/2541306.html
   http://blog.csdn.net/hijiankang/article/details/9173877
3. 是否对主要查询的字段创建了索引？
4. 测试数据是否有效？（尽可能按照真实场景来准备测试数据）
5. 是否须要限制用户的数据查询范围？
6. 是否须要优化业务结构？
   是否真的须要为用户提供一个查看几十万页的数据的页面？这样的数据对于用户来讲，每每是没用的。咱们应该在功能模块方面从新设计？
7. 不要使用 JOIN，而是使用 IN 语句。
8. 不要查询全字段，而是只查询 ID。

 

例如，下面这个 SQL，在压力测试 1000 万行数据时，已经须要 8 秒左右：

SELECT * FROM
(
    SELECT T.*, ROWNUM RN
    FROM 
    (
SELECT *
FROM "T_PRIMITIVEDETAIL" "T0"
WHERE "T0"."ORDERGOODSDATE" >= :p0 AND "T0"."ORDERGOODSDATE" <= :p1 AND "T0"."CORPORATION" = :p2 AND "T0"."DBI_ISPHANTOM" = :p3
ORDER BY "T0"."ID" ASC
    ) T
    WHERE ROWNUM <= 5000010
)
WHERE RN >= 5000000
--Parameters:2016/5/1 0:00:00,2016/5/31 23:59:59,"惠州酷友网络科技有限公司","0"

 

ID 列和 ORDERGOODSDATE 列都是创建了索引的，同时也为 ORDERGOODSDATE 列创建了表分区。通过几回测试，发现经过索引列排序进行查询速度仍是较慢（索引 Id 列：首次5秒，后面都是2.3秒；有索引的时间列：6秒；不排序：2秒）。

同时，咱们还对分页 SQL 进行的测试。目前有三种较为通用的分页格式：

1.根据ROWID来分
select * from t_xiaoxi where rowid in(
  select rid from (
    select rownum rn,rid from(
     select rowid rid,cid from
     t_xiaoxi  order by cid desc
    ) where rownum<10000
  ) where rn>9980
)
order by cid desc;
2.按分析函数来分
select * from (
  select t.*,row_number() over(order by cid desc) rk from t_xiaoxi t
) where rk<10000 and rk>9980;
3.按ROWNUM来分
select * from(
  select t.*,rownum rn from(
    select * from t_xiaoxi order by cid desc
  ) t where rownum<10000
) where rn>9980;

结果发现，原来的分页格式，效率是最高的。下面的 SQL 查询须要 4 秒：

select * from (
  select t.*,row_number() over(order by id ASC) rk from T_ENTERPRISETRANSACTION t
) where rk <= 5000010 and rk >= 5000000

因为咱们的分页 SQL 是自动生成的，因此格式方面咱们要保留必定的通用性，同时性能不能太差。因此仍是决定继续保留原有的格式。

前面几个优化方案没有成功。咱们就看了一下测试人员插入的一千条数据。原来这些数据的时间都是同一天的！！！形成了分区和索引失效。将数据按照真实场景录入后，不到 1s 就查询出来了。

另外，第 6 条：有 50 万页数据的页面，不该该设计给客户看到。因此我让项目组的同这考虑是否须要删除这个页面，换一种实现方案。

第8条，不查全字段，只查 ID：测试后，也有了比较明显的效果。

SELECT ID FROM
(
    SELECT T.*, ROWNUM RN
    FROM 
    (
SELECT ID
FROM "T_ENTERPRISETRANSACTION" "T0" 
--order by T0.Id desc
--order by T0.DBI_CreatedTime
--order by T0.tradeDate
    ) T
    WHERE ROWNUM <= 5000010
)
WHERE RN >= 5000000
--0.6秒
SELECT * FROM "T_ENTERPRISETRANSACTION" "T0" WHERE ID IN (7853679,7853680,7853681,7853682,7853683,7853684,7853685,7853686,7853687,7853688,7853689)
--0.1秒

一共只须要 0.7 秒。

 

常见问题三：大数据导入性能优化

---

公司产品的一个重要模块是一个数据导入引擎。基于 WF4 引擎，配合必定的活动，来实现从文件到数据库的导入。即：读取文件 –> 大量数据格式转换逻辑 & 大量业务逻辑 –> 导入数据库。

因为逻辑很是复杂，因此咱们并无把这些逻辑放到数据库中去编写存储过程，而是基于内存中的领域实体来执行业务逻辑。

对于此程序的优化步骤：

1. 经过性能监控工具，找到性能损耗的核心位置，再针对该位置出方案进行优化。
   这一步应该做为第一个步骤。开发者在对性能进行优化时，每每出现“想固然”地去分析、优化的行为，最终是花费了时间也没有优化到点上！因此这里首重提出这一步骤。先让工具去帮咱们找到这些核心位置！
2. 下降数据库访问次数。（此项检查是全部数据库访问程序的首要优化方案，也是最容易出现问题的地方）。
   1.1 解决 ORM 中的 N+1 问题。
   1.2 在内存中一次性准备好数据后，再插入到数据库中。
   1.3 对于导入大数据量到数据库中，采用批量导入方案，而非逐条导入方案。
3. 多线程技术。
   因为数据导入程序是 IO 密集型 + CPU 密集型操做，可是两者的运行阶段不一样。因此合理地采用多线程，能够大大提高执行效率。
   使用多线程时，要注意线程安全的问题：尽可能不要有太多的共享资源（文件、数据库中的行）；共享资源要加锁（文件加锁、内存加锁、数据库事务（事务的级别））。
   另外，提早为各个线程准备好一些共用的数据，也能够优化一些没必要要的 IO。
4. 优化核心大数据的循环，以及嵌套循环的核心循环中的代码便可。这些位置的代码，须要到处当心，优化到极致。
   核心循环中，不要用 LINQ To Object：一个 Linq To Object 操做，至少生成了三个轻量级对象：一个委托、一个实现 IEnumerable 接口的对象，以及遍历集合时，生成的一个 Enumerator。
   核心循环中，要尽可能减小循环的次数。例如：1000万数据和100万数据作循环匹配，不优化的循环就须要执行 1000万*100万次。因此咱们须要引入一些算法来优化没必要要的循环次数。
   只须要优化核心循环，不须要优化全部的代码。LINQ To Object 该用的时候，还要用。 

 

小结

---

本文对公司几个项目遇到的共性问题进行了总结。

但愿能对其它的项目组有所帮助。也但愿能收集到更多的优化建议。