性能優化相關

性能優化相關
1.前端
1.1請求性能優化
1）請求方式異步
2）請求發送內容用gzip壓縮

1.2Js文件按需導入
類似如下方式
Ext.require([
‘Ext.Gc3.CntTypeHelp’,
‘Ext.Gc3.Dept’,
‘Ext.Gc3.Stamps’,
‘Ext.Gc3.YsflHelp’,
‘Ext.Gc3.CntKgHelp’, ‘Ext.Gc.GcNumber’, ‘Ext.Gc.GcNumber’
]);
1.3 UI渲染相關（框架ExtJs4.2）
1）grid控件的數據量大時需要虛擬滾動：
在grid的plugins數組內部添加,{ ptype: ‘bufferedrenderer’ }即可

2)grid的數據大量導入需要用loadData(record)
3)grid修改數據數據時比如需要修改多行數據然後循環操作store進行set的需要在改數據之前Ext.suspendLayouts(); //停止刷UI 然後在修改set完之後Ext.resumeLayouts(true);//開始刷UI
4)單據打開時一定要先渲染UI不要在刷完數據之後再去渲染，提高用戶體驗
5)多Tab頁的單據需要懶加載需要進行懶加載

2.後端
1）不要在Controller循環find，不然很容易造成數據庫連接數過多客戶連不上

首先這會增加連接數，其次與數據庫交互是很耗性能的，在數據量不大內存足夠的情況下應儘量減少和數據庫交互的次數。正確應如下

也可使用LoadWithPage用特定的sql語句去滿足查詢
2）Codetoname的條數不宜過多（幾十條）當上千條時很容易降低取數效率，這時其實應該考慮表結構合理性
![在這裏插入圖片描述](https://img-blog.csdnimg.cn/2019122821484795.png其原因也是通過與數據庫交互查出幫助內的數據再通過反射將值賦到實體上，由於用的in而一次性
3）循環層數不應超過2層即邏輯複雜度不應大於n2應控制nlogn內
一般服務器每秒運算次數爲1000,000,000如果n3複雜度1000條數據隨便跑一下就要1s這是很難接受的事情，
4）保存的條數過多時可以考慮用RulerHelper.BatchSave()方法
批量插入幾千條只需幾s很可靠
5）只是修改某些字段值時應該用update
Save會執行很多不必要的檢測邏輯會損耗一定性能
3.Sql
1）對錶建立合適的索引：
避免對索引字段進行計算操作
避免在索引字段上使用not，<>，!=
避免在索引列上使用IS NULL和IS NOT NULL
避免在索引列上出現數據類型轉換
避免在索引字段上使用函數
避免建立索引的列中使用空值。
避免索引列進行or操作
2）left join 有時比 join的效率更高
如下sql語句：
select sonACD.ID
from
MN_ACD_DETAIL as sonACD
left join
MN_ACD_DETAIL as inbound
on sonACD.ANI=inbound.ANI
left join
call_detail_record as cdr
on sonACD.UCID=cdr.ucid
where
sonACD.ANSWER_TIME!=0
group by
sonACD.ID

select sonACD.ID
from
MN_ACD_DETAIL as sonACD
inner join
MN_ACD_DETAIL as inbound
on sonACD.ANI=inbound.ANI
inner join
call_detail_record as cdr
on sonACD.UCID=cdr.ucid
where
sonACD.ANSWER_TIME!=0
group by
sonACD.ID

在數據庫跑時發現前者明顯比後者快
查詢執行計劃發現，left join時只打描MN_ACD_DETAIL一次，而inner join時MN_ACD_DETAIL掃描兩次，call_detail_record 一次！而原因也就在這。
通過查詢開銷可以發現前者需要合併聯接兩次而後者在合併聯接上打開銷爲0%，後者所有的開銷都用在聚集索引掃描上，前者先查出了sonACD 與inbound 聯接的結果再與call_detail_record 聯接返回，
而left join必定有數據庫對其優化，以sonACD 爲主同時索引inbound 與cdr 查到符合條件立即返回。
這就是Left Join 有時比Join快的原因
3）用exist 和not exist代替 in和not in
4）