性能优化相关

性能优化相关
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）