项目性能优化点整理

** procedure

1. 预加载数据库数据到内存

  读DB的订单，性能提高了近十倍（10分钟处理降低到1分钟之内处理）

2. sql索引，去掉逻辑主键的聚集索引，对domain和manufactory建立聚集索引

  1. 使得页查询由几千次降低到49次

3. 读文件的930订单由10分钟降低到4分钟

  1. log4j时要输出行号， 调用log4j的log format（%c{1}:%L），它会Newthrowble，结

果就复制了log的堆

栈，导致性能下降

     log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd

HH:mm:ss,SSS} %5p %c{1}:%L - %m%n

     改为

     log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd

HH:mm:ss,SSS} %5p - %m%n

  2. 缓存正则表达式的pattern.compile结果

     1. new pattern.compile()中会newcomplie对象1亿多次，加缓存下降到2万次

4. 4分钟订单，在compareLinkAssignmentPriority里的printCompareLog被调用200万

次，耗时近2分钟

   log4j: BufferIO == true;

  log4j: BufferSize == 131072;

  调了4次log.info,原来是27，33，33，32秒,改完缩短到了8，20，20，19秒左右 [修改完

CustomizeLogFactory方法里的getAppender方法里的FileAppender构造函数也加

上buffer缩短到了1，9，9，8秒

左右]

  改完之后订单只要两分多钟就能跑完

5. server tunning

  1. 在Server上分别跑jar（读file）和war包（读db）总时间是50多秒，engine就用了46秒。

（对于jar包，读file和读

db时间几乎一样）

  2. 看soap调用war包时，由于是异步的所以也没多大意义

     SalesOrderTransferRequest是ecc被调用的接口

     SalesOrderEndPoint-->processSalesOrder

6. engine tunning

  1. 7919order 102秒的newc中33秒在初始化

     1. fastFaild

        1. explode --> WildCard class中matches的pattern.compile被调用级别为

千万次级 (两

千万次左右)

            这里缓存pattern不奏效，这里的pattern都是rulefiles里的，每次都不一样

（这里记录时间出现了错误，以为不奏

效）

            failFast 添加后由15秒变为2秒

        2. initiallize --> FileRuleQuery class --> searchByComponentNamemethod

            no failFast 25.57秒 have failFast 5.214秒

        3. tips: 先减少match的单次时间，再减少match被调用次数，实在不行，就需要

看在业务上看是否有结构调整

            1. 把componentName的rule构造数据结构：

               1. 树形结构

                  还可以想办法降低树的高度

               2. hash--有个问题是星号就匹配不到hash值

     2. usage里头有个map可以改为静态的

     3. assembler -- > 20多秒变为6秒

        1. compairRequiredLink --> printCompareLog --> log.info

            就算关闭了log，string format还是执行了，导致这部分时间占了很多（4 ：

26）

            解决：推迟format的执行，修改log.info接口-->log.formatInfo

            时间变化 7 7 5 --> 0.131, 0.221, 0.122 单位：秒

  2. sbb tunning 优化前：总共engin42.09S cov和sbb占了一半, sbb 18.5S --> 3.177s

     handle时间占了几乎所有时间

     打时间找到在SBBFilterChainHandler--> handle --> SBBFileRuleQuery --> queryDomain --> isMatch --> 将正则complie改为自定义match

     将query时间和filter时间分开

     1. load

        query --> loadData --> loadRuleFile 读了5000次 6S --> 加缓存结

果：25次几十ms

     2. query 

        merge loadRule and queryData(反射掉了600多次，merge后没有这个method)

，去掉了一些重复的

读file的逻辑，并缓存一些结果

        8S --> 307ms

  3. initialize --> evaluate usage rule 6S

     把生成log里构造字符串的语句，在没有log的时候，不进行stringFormat

  4. neeOutput true vs false

     56.64 vs 26.33

7. db 里的ismatch改动

  1. 思路

     1. 先替换，看时间是否提高

     2. 再抽出共有方法

  2. 修改了newc的ismatch -- 做了缓存 -- 将isMatch抽到了ModelingFile中