引言最近一段时间系统新版本要发布在beta客户测试期间暴露了很多问题除了一些业务和异常问题外其他都集中在性能上。有幸接触到这些性能调优的机会当然要学习总结了。性能优化是一个老生常谈的问题了典型的性能问题如页面响应慢、接口超时服务器负载高、并发数低数据库频繁死锁等。而造成性能问题又有很多种比如磁盘I/O、内存、网络、算法、大数据量等等。我们可以大致把性能问题分为四个层次代码层次、数据库层次、算法层次、架构层次。所以下面我会结合实际性能优化案例和大家分享下性能调优的工具、方法和技巧。2. 先说心态说到性能问题你可能首先就想到的是麻烦或者头大因为一般性能问题都比较紧急轻则影响客户体验重则宕机导致财务损失而且性能问题比较隐蔽不易发现。因此一时间无从下手而这时我们就很容易从心底开始去排斥它不愿接这烫手的山芋。而恰巧性能调优是体现程序员水平的一个重要指标。因为处理bug、崩溃、调优、入侵等突发事件比编程本身更能体现平庸程序员与理想程序员的差距。当面对一个未知的问题时如何定位复杂条件下的核心问题、如何抽丝剥茧地分析问题的潜在原因、如何排除干扰还原一个最小的可验证场景、如何抓住关键数据验证自己的猜测与实验都是体现程序员思考力的最好场景。是的在衡量理想程序员的标准上思考力比经验更加重要。所以若你不甘平庸请拥抱性能调优的每一个机会。当你拥有一个正确的心态你所面对的性能问题就已经解决了一半。3. 再说技巧拿到一个性能问题不要忙着先上工具先了解问题出现的背景问题的严重程度。然后大致根据自己的经验积累作出预估。比如客户来了个性能问题说系统宕机了已经造成资金损失了。这种涉及到钱的问题大家都比较敏感根据自己的level决定是否要接这个锅。这不是逃避而是自知之明。了解问题背景之后下一步就来尝试问题重现。如果在测试环境能够重现那这种问题就很好跟踪分析。如果问题不能稳定重现或仅能在生产环境重现那问题就相对比较棘手这时要立刻收集现场证据包括但不限于抓dump、收集应用程序以及系统日志、关注CPU内存情况、数据库备份等等之后不妨再尝试重现比如恢复客户数据库到测试环境重现。不管问题能否重现下一步我们就要大致对问题进行分类是代码层次的业务逻辑问题还是数据库层次的操作耗时问题又或是系统架构的吞吐量问题。那如何确定呢而我倾向于先从数据库动手。我的习惯做法是使用数据库监控工具先跟踪下Sql耗时情况。如果监控到耗时较长的SQL语句那基本上就是数据库层次的问题否则就是代码层次。若为代码层次再研究完代码后再细化为算法或架构层次问题。确定问题种类后是时候上工具来精准定位问题点了Sql耗时问题推荐使用免费的Plan Explorer 分析执行计划。代码问题定位优先推荐使用VS自带的Performance Analysis其次是RedGate的性能分析套件.NET Developer Bundle然后还有Jet Brains的dotTrace -- .NET performance profilerdotMemory-- .NET memory profiler再然后就是反人类的Windbg等等。精准定位问题点后就是着手优化了。相信到这一步就是优化策略的选择了这里就不展开了。优化后最后当然要进行测试了毕竟优化了多少我们也要做到心里有谱才行。以上啰啰嗦嗦有点多下面我们直接上案例。4. 案例分享下面就分享下我针对代码层面、数据库层面和算法层面的优化案例。4.1. SQL优化案例案例1客户反馈某结算报表统计十天内的数据耗时10mins左右。由于前几天刚学会用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 0WHERE 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主要是想做去重处理很显然选用了错误的方案。改后代码如下string sqlMerge string.Format(merge into {0} t1using(select min(Fseq) fseq,Fentryid from {0} t2 group by fentryid) t3 on (t1.fentryid t3.fentryid and t1.fseq t3.fseq)when matched thenupdate set t1.FDIRECTQTY 0, t1.FALLAMOUNT 0, sJoinDataTempTable);listSqlObj.Add(new SqlObject(sqlMerge, new List SqlParam ()));sbSql.Clear();改后测试相同数据量耗时由10mins降到10s左右。4.2. 代码优化案例案例2客户反馈销售订单100条分录行保存进行可发量校验时耗时7mins左右。拿到这个问题后本地重现后监控sql耗时没有异常那就着重分析代码了。因为可发量校验的业务逻辑极其复杂又加上又直接再一个类文件实现该功能3500行的代码加上零星注释真是让人避之不及。逃避不是办法还是上工具分析一把。这次我选用的时VS自带的Performance Profiler开发环境下极其强大的性能调优工具。针对我们当前案例我们仅需要跟踪指定服务对应的dll即可使用步骤如下Analyze--Profiler--New Performance Session打开Performance Explorer找到新添加的Performance Session右键Targets然后选择Add Target Binary添加要跟踪的dll文件即可将应用跑起来选中Performance Session右键Attach对应进程即可跟踪分析性能了在跟踪过程中可随时暂停跟踪和停止跟踪跟踪结束后本案例跟踪到的采样结果如下图同时Performance Profiler也给出了问题的建议如下图其中第1、4条大致说明程序I/O消耗大第一代的GC上存在未及时释放的垃圾占比过高。而根据上图的采样结果我们可以直接看出是由于再代码中频繁操作DataTable引起的性能瓶颈。走读代码发现的确如此所有的数量统计都是在代码中循环遍历DataTable进行处理的。而最终的优化策略就相当于一次大的重构将所有代码中通过遍历DataTable的计算逻辑全部挪到SQL中去做。由于代码过多就不再放出。案例3客户反馈批量引入1000张订单耗时40mins左右且容易中断。同样我们还是先尝试本地重写。经测试批量引入101张单据就耗时5mins左右。下一步打开Sql监控工具也未发现耗时语句。但考虑到是批量导入操作虽然单个耗时不多但乘以100这个基数就明显了。下面我们就使用RedGate的Ants Performance Profiler跟踪一下。该工具比较直观可以同时监控代码和SQL执行情况。第一步New Profiler Session第二步进行设置如下图。根据自己的应用程序类别选择相应的跟踪方式。