ASP.NET效能監控和最佳化入門

　關鍵要點：

• 只有與應用指標相關聯，基礎設施指標才能最大發揮作用。

• 
  

• 高效效能最佳化的關鍵在於效能資料。

• 
  

• 一些APM工具為ASP.NET提供了開箱即用的支援，這樣入門使用ASP.NET僅需最小限度的初始設定。

• 
  

• 程式碼分析工具為程式效能給出了最為詳盡的視圖。

• 
  

• 輕量級分析工具給出了網頁效能的即時視圖，可用在開發環境和生產環境中。

　　“這個網頁開啟太慢了！”，對Web網站這樣的抱怨是經常性的和普遍性的，尤其是自從Web應用開始逐漸替代案頭應用以來。雖然Web帶來了全球交付這樣的理想特性，但是也在效能層面帶來了相應的挑戰。

　資料擷取與使用的基本原理

　　使用者給了你一個“龜速”網頁的url，那好，你該怎麼做呢？網頁開啟慢的問題是源自於哪裡？是一開始就是這麼慢嗎？是對所有使用者都很慢嗎？要解決網頁開啟慢的問題並且確保在一周后不會再次變慢，有許多諸如此類的問題需要得到解決。

　　雖然在網上可以搜尋到一些效能最佳化的資料，但它們通常都是關於Jit、記憶體回收、SQL查詢最佳化、ORM陷阱等這樣一些特定主題的。考慮到實現最佳化的美好前景是誘人的，這裡冒出了這樣的一個問題：針對當前的效能問題，如何知道所選定的最佳化方法將會切實地產生好的結果？

　　無疑在這個工作中的某一環是有所缺失的。我們需要能可持續地找到效能問題所在的方法。通過使用該方法，我們能發現系統中較慢的部分，並有切實措施支援我們對效能問題的診斷。掌握了效能問題所在，我們就可以進一步地確定是否需要進行效能改進，並對利益相關者解釋所有這一切。

　　對於所發現的上述效能問題，進行準確地甄別是更有效處理方法。問題在一開始可能並非是一個網頁載入慢的問題。在存在逾時的情況下（例如負載平衡器可能幾秒後才會為串連提供服務），完全無法被區分開這是一個死結問題或是回應時間慢的問題，因為這兩個問題導致了同樣的結果，就是產生了逾時。這需要資料去找到導致問題的真正原因。

　　為了闡明準確甄別效能問題的重要性，下面列舉了一些導致Web應用響應慢的可能問題排查點：

• JavaScript響應慢；

• 
  

• 資源載入中的產生了阻塞；

• 
  

• 使用者端存在代理；

• 
  

• DNS問題；

• 
  

• ISP或網路問題；

• 
  

• 交換器和路由器；

• 
  

• 負載平衡器；

• 
  

• 應用代碼（包括第三方軟體庫）；

• 
  

• HTTP伺服器（例如有時是ASP.net或IIS）；

• 
  

• 第三方服務，例如：支付服務提供者、地圖服務提供者等；

• 
  

• 子系統，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。

　　還可以羅列出更多的效能問題排查點，這取決於需處理系統的複雜度和規模。在如此之多的系統組件都可影響效能最佳化問題的情況下，如何才能確診效能問題呢？答案概括為一個詞：資料。你需要來自於每個系統組件的、相關且有意義的資料。對於Web應用響應慢的問題，資料可以證明每個系統組件是對問題是有影響的還是完全無關的。

　　資料在手，就可以開始從上述列表中按你的思路去抽取問題排查點進行分析，這類似於在排序樹中進行尋找。每次在樹中向下走一層，就越接近於效能問題的細節和實質，依次甄別效能問題是否存在於：

• 用戶端，伺服器端或是兩者之間的某處？

• 
  

• 響應慢的JavaScript、渲染或是資源阻塞？

• 
  

• 負載平衡器、Web伺服器、任一子系統或是第三方軟體？

　　在這樣樹中逐層下行時，效能問題會變得越來越清晰。對於每個層次上的問題排查點，定位效能問題所需的資料必須要與對應的問題精度相匹配。這時有必要去使用效能分析工具或SQL執行計畫這樣的工具。

　　為有效地利用時間，很有必要重申一下Amdahl定律：

無論一個任務改進的程度如何，該任務中沒有從改進中受益的部分限制了理論上的任務加速。

　　例如在一個Web請求中，假定需要100毫秒的伺服器處理時間和5秒的SQL查詢時間。即使你可以將伺服器處理時間最佳化到低於1毫秒，但是這對整體回應時間的改進很小，也就是從5.1秒變成5秒。改進SQL處理所需的5秒時間是潛在收益最大的最佳化。

　架構問題

　　這種逐層釐清最佳化問題所在的自頂向下方法，對於局限在單一頁面中的最佳化問題具有很好的效果。那麼應用於跨越多個頁面的最佳化問題上時效果又如何呢？例如，一些頁面所存在的間歇性地開啟慢問題，是由於子系統跟不上整體工作節奏，或是由於系統中存在某個再次重啟可能就無法繼續工作的老舊網路交換器。

　　這種情況下，側重於應用的監控方法顯示出它的局限性所在。這需要更多的軟體層面和硬體層面上的指標，用於對系統中的每個組件進行評估。

　　在硬體層面，首先所能想到就是web伺服器和資料庫伺服器，但它們只是冰山的一角。必須要識別和監控所有系統中的硬體組件，這包括：伺服器、網路交換器、路由器、負載平衡器、防火牆、SAN等。

　　鑒於系統管理員的常規工作就是硬體監控，可能對於系統管理員而言上述的所有指標是顯而易見的。但是這裡有個重要警告：如果將這些硬體指標從軟體指標中分離處理，那麼從效能角度看所有這些硬體指標中的大部分是毫無用處的。換句話說，指標只有置於相應的環境中才能發揮最大作用。

　　例如，在一些情況下可能在資料庫伺服器上CPU佔用率平均達50%是完全正常的，但是對於其它伺服器而言這就是個定時炸彈。50%的CPU佔用率，如果是在峰值時刻這意味著仍有很大空間去運行更繁重的任務。但如果是在閑暇時間段中而50%的CPU佔用率頻繁發生，這就意味著應用可能無法承受傳入請求的突發峰值。

　　底線就是，為評估系統的健康度，CPU、記憶體和磁碟等全系統範圍指標必須要與應用指標相關聯。為給出更完全的系統健康情況視圖，可以對請求輸送量這樣的應用指標和CPU佔用率這樣的系統指標進行可視化。

　應用效能管理（Application Performance Management，APM）工具

　　APM工具提供資料擷取、資料存放區和資料視覺效果這些基礎性操作。通常是由代理負責採集資料並將資料發送給資料存放區，並使用Web介面以集中在Web請求上的儀錶盤方式對資料進行可視化。

　　APM可用於：

• 對Web應用效能做整體可視化；

• 
  

• 對特定的Web請求效能進行可視化；

• 
  

• 在Web應用效能變差時或者多個錯誤出現時，自動發送警示；

• 
  

• 在業務量大時，對應用的回應程式式進行驗證。

　　在這裡給出了執行個體。

　　下面並非詳盡地列出了支援對ASP.NET和IIS開箱即用的APM工具清單：

• NewRelic APM

• 
  

• Application Insights

• 
  

• AppDynamics

• 
  

• Stackify

　基礎設施監控工具

　　基礎設施監控工具在主機層面採集指標，這可更完整地反映效能。這些指標是在硬體和軟體層面採集的。

• DataDog

• 
  

• OpServer - Open Source

　輕量級分析工具

　　輕量級分析工具為特定Web請求提供了高層次的指標，並在開發人員瀏覽Web頁面時就可提供即時反饋。這些工具可用於所有的環境類型中（包括開發環境、QA驗證、類比環境、生產環境等），因此非常適合於對特定頁面效能的快速評估。

　　與相應的具有完全功能的分析工具相比，輕量級分析工具的本質差異在於它們並非附屬於過程，這意味著在使用輕量級分析工具時無需操心它們所產生的開銷。

　　在開發環境中，輕量級分析工具對當前正編寫的代碼提供了即時反饋。這對於發現N+1或回應時間慢等問題是非常有用的，因為回應時間總是顯示在頁面的一角上。

• 開源的MiniProfiler

• 
  

• 開源的Glimpse

　用效能計數器填補空白

　　Windows系統中的效能計數器（Performance counter）提供了硬體和軟體層次上不同方面的指標。監控工具通常以效能計數器為報告方式，例如CPU和記憶體佔用情況。但是通常會缺失一些有用的計數器，例如記憶體回收時間等。最切實可行的入門方法是使用基本欄表並在迭代中添加必要的相關計數器。此外，使用perfmon對效能計數器進行即時地採集和可視化是可行的。在很多情況下，將使用者定製指標或外掛程式與APM工具進行整合也是可行的。

　SQL工具

　　由於在很多應用中普遍地使用了資料庫，持久層（即SQL資料庫）常常成為效能的瓶頸。用於SQL監控的專業工具可提供資源使用指標，以及一些特定的指標，例如等待時間、每秒編譯次數等，在這裡僅列舉幾個。

　　在提供下列資料情況下，可以發現一些類型的問題並可對效能進行改進：

• 在一個或數個查詢上存在過度的輸送量；

• 
  

• 過度的CPU佔用，這暗示了查詢問題的存在或者是索引的缺失；

• 
  

• 可被緩衝的高輸送量查詢。

　　SQL監控工具包括：

• RedGate SQL Monitor

• 
  

• SQLSentry Performance Advisor

　其它的持久系統

　　所有子系統都需要在某種程度上進行監控。對於低輸送量或非關鍵的系統，簡單的資料擷取和可視化即足矣。在此外的情況下則需要更加進階的、專業的監控。

　程式碼分析工具

　　當已確診某個特定頁面或程式碼片段檢測是響應慢的，程式碼分析工具可為效能問題評鑑提供最詳盡的視圖。程式碼分析工具還可為資料庫查詢和Web請求這樣的外部調用提供了精準視圖。

　　分析工具：

• Redgate Ants

• 
  

• JetBrains dotTrace

　記憶體分析工具

　　記憶體監控和記憶體回收指標有助於潛在問題的檢測。但這些指標在顯示了存在問題的同時，通常並未給出問題的所在。如果需要隊記憶體和記憶體回收問題進行深入地探究，記憶體分析工具就可派上用場。

　　分析工具：

• JetBrains dotMemory

• 
  

• RedGate Ants Memory Profiler

　使用者端分析工具

　　效能問題也可能來自於前端。當前這個問題十分常見，因為以JavaScript主導的單頁應用的大量湧現。所有的主流瀏覽器都已嵌入了諸如程式碼分析和記憶體分析這樣的工具。顯示事件和請求的序列的工具有利於一眼就確定問題是源於前端還是後端。

　　工具：Tools:

• Google Chrome Timeline

• 
  

• Firefox

　頁面分析工具

　　高層次用戶端工具為發現並解決效能問題的提供了便利著手點。這些工具可以針對回應時間問題的產生根源提供高層次的視圖，並給出一些相應的建議。例如Google的PageSpeed Insights就是這樣的一個免費工具。

　　系統效能相關的因素和工具的數量是非常之多，這看上去似乎十分複雜。但是它們可以用一個詞進行概括：資料。對系統有一個清晰的和準確的視圖，這使得推理效能問題成為可能。這也使你可以在現場學習如何去解決效能問題，因為效能指標和圖表將會引導你去發現到底是什麼影響了系統效能。