【技巧沙龙】AI开辟者拭魅战营-7分钟打造1个定制技能。7月22号，我们等你一路！

机能优化 1. 引言

比来一段时光，体系新版本要宣布，在beta客户测试时代，裸露了很多问题，除了一些营业和异常问题外，其他都集中在机能上。有幸接触到这些机能调优的机会，当然要进修总结了。

机能优化是一个老生常谈的问题了，典范的机能问题如页面响应慢、接口超时，办事器负载高、并发数低，数据库频繁逝世锁等。而造成机能问题又有很多种，比如磁盘I/O、内存、收集、算法、大年夜数据量等等。我们可以大年夜致把机能问题分为四个层次：代码层次、数据库层次、算法层次、架构层次。

下面就分享下我针对代码层面、数据库层面和算法层面的优化案例。

4.1. SQL优化案例

所以下面我会结合实际机能优化案例，和大年夜家分享下机能调优的对象、办法和技能。
2. 先说心态
说到机能问题，你可能起首就想到的是麻烦或者头大年夜，因为一般机能问题都比较紧急，轻则影响客户体验，重则宕机导致财务损掉，并且机能问题比较隐蔽，不易发明。是以一时光无大年夜下手，而这时我们就很轻易大年夜心底开端去排斥它，不肯接是日手的山芋。
拿到一个机能问题，不要忙着先上对象，先懂得问题出现的背景，问题的严重程度。然后大年夜致根据本身的经验积聚作出预估。比如客户来了个机能问题说体系宕机了，已经造成资金损掉了。这种涉及到钱的问题，大年夜家都比脚绫囚感，根据本身的level，决定是否要接这个锅。这不是回避，而是自知之明。
懂得问题背景之后，下一步就来测验测验问题重现。如不雅在测试情况可以或许重现，那这种问题就很好跟踪分析。如不雅问题不克不及稳定重现或仅能在临盆情况重现，那问题就比拟较较棘手，这时要急速收集现场证据，包含但不限于抓dump、收集应用法度榜样以及体系日记、存眷CPU内存情况、数据库备份等等，之后不妨再测验测验重现，比如恢复客户数据库到测试情况重现。
不管问题可否重现，下一步，我们就要大年夜致对问题进行分类，是代码层次的营业逻辑问题照样数据库层次的操作耗时问题，又或是体系架构的吞吐量问题。那若何肯定呢？而我偏向于先大年夜数据库着手。我的习惯做法是，应用数据库监控对象，先跟踪下Sql耗时情况。如不雅监控到耗时较长的SQL语句，那根本上就是数据库层次的问题，不然就是代码层次。若为代码层次，再研究完代码后，再细化为算法或架构层次问题。
肯定问题种类后，是时刻上对象来精准定位问题点了：

Sql耗时问题，推荐应用免费的Plan Explorer分析履行筹划。

代码问题定位，优先推荐应用VS自带的Performance Analysis，其次是RedGate的机能分析套件.NET Developer Bundle；然后还有Jet Brains的dotTrace -- .NET performance profiler，dotMemory-- .NET memory profiler；再然后就是反仁攀类的Windbg；等等。
精准定位问题点后，就是着手优化了。信赖到这一步，就是优化策略的选择了，这里就不展开了。
优化后，最后当然要进行测试了，毕竟优化了若干，我们也要做到心里有谱才行。
以上啰烦琐嗦有点多，下面我们直接上案例。
4. 案例分享
案例1：客户反馈某结算报表统计十天内的数据耗时10mins阁下。

string sqlMerge = string.Format(@"merge into {0} t1using(select min(Fseq) fseq,Fentryid from {0} t2 group by fentryid) t3 offset="1">4.2. 代码优化案例因为前几天刚学会用RedGate的分析对象，拿到这个问题，本地测验测验重现后，就直接想应用对象分析。然而，这对象在应用webdev模式起站点时，老是报错，而当不时一根筋，老是想解决这个对象的报错问题。结不雅，白白搞了半天也没搞定。最后不得已放弃对象，转而选择应用sql server profiler去监控sql语就砟瓯。一跟踪没紧要，问题就直接裸露了，全部全屏的反复sql语句，如下图。
这下问题就很明显了，八成是代码在轮回拼接sql履行语句。根据抓取到sql关键字往代码中去搜刮，不雅然如斯。
而刚巧，机能调优是表现法度榜样员程度的一个重要指标。
#region更新三张表数据浇忧⒛中心临时表数据，有上浪荡据的直接调拨单分多次下推时，只计算一次的调拨数量和价税合计string sSql = string.Format(@"SELECT FENTRYID FROM {0} GROUP BY FENTRYID HAVING COUNT(FENTRYID) > 1", sJoinDataTempTable);using(IDataReader reader = DBUtils.ExecuteReader(this.Context, sSql)) {    while (reader.Read()) {        sbSql.AppendFormat(@"UPDATE {0} SET FDIRECTQTY = 0,FALLAMOUNT = 0 WHERE FSEQ NOT IN (SELECT TOP 1 FSEQ FROM {0} WHERE FENTRYID = {1}) AND FENTRYID = ({1});", sJoinDataTempTable, Convert.ToInt32(reader["FENTRYID"]));        listSqlObj.Add(new SqlObject(sbSql.ToString(), new List < SqlParam > ()));        sbSql.Clear();    }}#endregion
看到这段代码，咱先不评判这段代码的好坏，因为毕竟代码注释清楚，省了我们理清营业的工夫。这段sql主如果想做去重处理，很显然选用了缺点的筹划。改后代码如下：
案例2：客户反馈发卖订单100条分录行，保存进行可发量校验时，耗时7mins阁下。
拿到这个问题后，本地重现后，监控sql耗时没有异常，那就侧重分析代码了。因为可发量校验的营业逻辑极其复杂，又加上又直接再一个类文件实现该功能，3500+行的代码，加上零碎注释，真是让人避之不及。回避不是办法，照样上对象分析一把。	
			
 1/3    1 2 3 下一页 尾页	
			

　　推荐阅读
　　开启网络新纪元  思科带你感受一个前所未有的网络
            【技巧沙龙】AI开辟者拭魅战营-7分钟打造1个定制技能。7月22号，我们等你一路！

            
                
                    
                
                【51CTO.com原创稿件】仁攀类>>>详细阅读


本文标题：性能优化知多少
地址：http://www.17bianji.com/lsqh/36226.html
 1/2    1