最近一段時間，系統新版本要釋出，在beta客戶測試期間，暴露了很多問題，除了一些業務和異常問題外，其他都集中在性能上。有幸接觸到這些性能調優的機會，當然要學習總結了。
性能優化是一個老生常談的問題了，典型的性能問題如頁面響應慢、接口逾時，伺服器負載高、并發數低，資料庫頻繁死鎖等。而造成性能問題又有很多種，比如磁盤I/O、記憶體、網絡、算法、大資料量等等。我們可以大緻把性能問題分為四個層次：代碼層次、資料庫層次、算法層次、架構層次。
是以下面我會結合實際性能優化案例，和大家分享下性能調優的工具、方法和技巧。
說到性能問題，你可能首先就想到的是麻煩或者頭大，因為一般性能問題都比較緊急，輕則影響客戶體驗，重則當機導緻财務損失，而且性能問題比較隐蔽，不易發現。是以一時間無從下手，而這時我們就很容易從心底開始去排斥它，不願接這燙手的山芋。
而恰巧，性能調優是展現程式員水準的一個重要名額。
因為處理bug、崩潰、調優、入侵等突發事件比程式設計本身更能展現平庸程式員與理想程式員的差距。當面對一個未知的問題時，如何定位複雜條件下的核心問題、如何抽絲剝繭地分析問題的潛在原因、如何排除幹擾還原一個最小的可驗證場景、如何抓住關鍵資料驗證自己的猜測與實驗，都是展現程式員思考力的最好場景。是的，在衡量理想程式員的标準上，思考力比經驗更加重要。
是以，若你不甘平庸，請擁抱性能調優的每一個機會。當你擁有一個正确的心态，你所面對的性能問題就已經解決了一半。
拿到一個性能問題，不要忙着先上工具，先了解問題出現的背景，問題的嚴重程度。然後大緻根據自己的經驗積累作出預估。比如客戶來了個性能問題說系統當機了，已經造成資金損失了。這種涉及到錢的問題，大家都比較敏感，根據自己的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；等等。
精準定位問題點後，就是着手優化了。相信到這一步，就是優化政策的選擇了，這裡就不展開了。
優化後，最後當然要進行測試了，畢竟優化了多少，我們也要做到心裡有譜才行。
以上啰啰嗦嗦有點多，下面我們直接上案例。
下面就分享下我針對代碼層面、資料庫層面和算法層面的優化案例。
案例1：客戶回報某結算報表統計十天内的資料耗時10mins左右。
由于前幾天剛學會用RedGate的分析工具，拿到這個問題，本地嘗試重制後，就直接想使用工具分析。然而，這工具在使用webdev模式起站點時，總是報錯，而當時時一根筋，老是想解決這個工具的報錯問題。結果，白白搞了半天也沒搞定。最後不得已放棄工具，轉而選擇使用sql server profiler去監控sql語句耗時。一跟蹤不要緊，問題就直接暴露了，整個全屏的重複sql語句，如下圖。
這下問題就很明顯了，八成是代碼在循環拼接sql執行語句。根據抓取到sql關鍵字往代碼中去搜尋，果然如此。
看到這段代碼，咱先不評判這段代碼的優劣，因為畢竟代碼注釋清晰，省了我們理清業務的功夫。這段sql主要是想做去重處理，很顯然選用了錯誤的方案。改後代碼如下：
改後測試相同資料量，耗時由10mins降到10s左右。
案例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，第二步進行設定，如下圖。根據自己的應用程式類别，選擇相應的跟蹤方式。
針對這個問題，我們跟蹤到的調用堆棧和SQL耗時結果如下圖：
首先從調用堆棧中的Hit Count，我們可以首先看出它是一個批量過程，因為入口函數僅調用一次；第二個我們可以代碼中是循環處理每一個單據，因為Hit Count與我們批量引入的單據數量相符；第三個，突然來了個10201，如果有一定的數字敏感性的話，這次性能問題的原因就被你找到了。這裡就不賣關子了，101 x 101 = 10201。
是不是明白了什麼，存在循環嵌套循環的情況。我們走讀代碼确定一下：
好嘛，外層套了一個空循環卻什麼也沒做。修改就很簡單了，删除無效外層循環即可。
案例4：某全流程跟蹤報表逾時。
這個報表是用來跟蹤所有單據從下單到出庫的業務流程資料流轉情況。而所有的流程資料都是按照樹形結果存儲在資料庫表中的，類似這樣：
圖中的流程為：
銷售合同-->銷售訂單-->發貨通知單-->銷售出庫單
為了構造流程圖，之前的處理方法是把流程資料取回來，通過代碼構造流程圖。這也就是性能差的原因。
而針對這種情況，就是考驗我們平時經驗積累了。對于樹形結構的表，我們也是可以通過SQL來進行直接查詢的，這就要用到了SQL Server的CTE文法來進行遞歸查詢。關于遞歸查詢，可參考我這篇文章：SQL遞歸查詢知多少。這裡就不展開了。
性能調優是一個循序漸進的過程，不可能一蹴而就，重在平時的點滴積累。關于工具的選擇和使用，本文并未展開，也希望讀者也不要糾結與此。當你真正想解決一個問題的時候，相信工具的使用是難不住你的。
最後就大緻總結下我的調優思路：
調整心态，積極應對
了解性能背景， 收集證據， 嘗試重制
問題分類，先監控SQL耗時，大緻确定是SQL或是代碼層次原因
使用性能分析工具，确定問題點
調優測試
推薦連結：你必須知道的.NET Core開發指南
推薦連結：你必須知道的ML.NET開發指南
推薦連結：你必須知道的Office開發指南
推薦連結：你必須知道的IOT開發指南
推薦連結：你必須知道的Azure基礎知識
推薦連結：你必須知道的PowerBI基礎知識
<b></b> 關注我的公衆号『微服務知多少』，我們微信不見不散。 閱罷此文，如果您覺得本文不錯并有所收獲，請【打賞】或【推薦】，也可【評論】留下您的問題或建議與我交流。 你的支援是我不斷創作和分享的不竭動力！
作者：『聖傑』
出處：http://www.cnblogs.com/sheng-jie/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結，否則保留追究法律責任的權利。