如何監(jiān)控ASP.NET性能

小編給大家分享一下如何監(jiān)控ASP.NET性能，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

　關鍵要點：

• 只有與應用指標相關聯(lián)，基礎設施指標才能最大發(fā)揮作用。

• 
  

• 高效性能優(yōu)化的關鍵在于性能數據。

• 
  

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

• 
  

• 代碼分析工具為程序性能給出了最為詳盡的視圖。

• 
  

• 輕量級分析工具給出了網頁性能的實時視圖，可用在開發(fā)環(huán)境和生產環(huán)境中。

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

　數據采集與使用的基本原理

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

　　雖然在網上可以搜索到一些性能優(yōu)化的資料，但它們通常都是關于Jit、垃圾回收、SQL查詢優(yōu)化、ORM陷阱等這樣一些特定主題的?？紤]到實現(xiàn)優(yōu)化的美好前景是誘人的，這里冒出了這樣的一個問題：針對當前的性能問題，如何知道所選定的優(yōu)化方法將會切實地產生好的結果？

　　無疑在這個工作中的某一環(huán)是有所缺失的。我們需要能可持續(xù)地找到性能問題所在的方法。通過使用該方法，我們能發(fā)現(xiàn)系統(tǒng)中較慢的部分，并有切實措施支持我們對性能問題的診斷。掌握了性能問題所在，我們就可以進一步地確定是否需要進行性能改進，并對利益相關者解釋所有這一切。

　　對于所發(fā)現(xiàn)的上述性能問題，進行準確地甄別是更有效的處理方法。問題在一開始可能并非是一個網頁加載慢的問題。在存在超時的情況下（例如負載均衡器可能幾秒后才會為連接提供服務），完全無法被區(qū)分開這是一個死鎖問題或是響應時間慢的問題，因為這兩個問題導致了同樣的結果，就是產生了超時。這需要數據去找到導致問題的真正原因。

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

• JavaScript響應慢；

• 
  

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

• 
  

• 用戶端存在代理；

• 
  

• DNS問題；

• 
  

• ISP或網絡問題；

• 
  

• 交換機和路由器；

• 
  

• 負載均衡器；

• 
  

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

• 
  

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

• 
  

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

• 
  

• 子系統(tǒng)，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。

　　還可以羅列出更多的性能問題排查點，這取決于需處理系統(tǒng)的復雜度和規(guī)模。在如此之多的系統(tǒng)組件都可影響性能優(yōu)化問題的情況下，如何才能確診性能問題呢？答案概括為一個詞：數據。你需要來自于每個系統(tǒng)組件的、相關且有意義的數據。對于Web應用響應慢的問題，數據可以證明每個系統(tǒng)組件是對問題是有影響的還是完全無關的。

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

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

• 
  

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

• 
  

• 負載均衡器、Web服務器、任一子系統(tǒng)或是第三方軟件？

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

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

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

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

　架構問題

　　這種逐層厘清優(yōu)化問題所在的自頂向下方法，對于局限在單一頁面中的優(yōu)化問題具有很好的效果。那么應用于跨越多個頁面的優(yōu)化問題上時效果又如何呢？例如，一些頁面所存在的間歇性地打開慢問題，是由于子系統(tǒng)跟不上整體工作節(jié)奏，或是由于系統(tǒng)中存在某個再次重啟可能就無法繼續(xù)工作的老舊網絡交換機。

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

　　在硬件層面，首先所能想到就是web服務器和數據庫服務器，但它們只是冰山的一角。必須要識別和監(jiān)控所有系統(tǒng)中的硬件組件，這包括：服務器、網絡交換機、路由器、負載均衡器、防火墻、SAN等。

　　鑒于系統(tǒng)管理員的常規(guī)工作就是硬件監(jiān)控，可能對于系統(tǒng)管理員而言上述的所有指標是顯而易見的。但是這里有個重要警告：如果將這些硬件指標從軟件指標中分離處理，那么從性能角度看所有這些硬件指標中的大部分是毫無用處的。換句話說，指標只有置于相應的環(huán)境中才能發(fā)揮最大作用。

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

　　底線就是，為評估系統(tǒng)的健康度，CPU、內存和磁盤等全系統(tǒng)范圍指標必須要與應用指標相關聯(lián)。為給出更完全的系統(tǒng)健康狀況視圖，可以對請求吞吐量這樣的應用指標和CPU占用率這樣的系統(tǒng)指標進行可視化。

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

　　APM工具提供數據采集、數據存儲和數據可視化這些基礎性操作。通常是由代理負責采集數據并將數據發(fā)送給數據存儲，并使用Web界面以集中在Web請求上的儀表盤方式對數據進行可視化。

　　APM可用于：

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

• 
  

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

• 
  

• 在Web應用性能變差時或者多個錯誤出現(xiàn)時，自動發(fā)送告警；

• 
  

• 在業(yè)務量大時，對應用的響應方式進行驗證。

　　在這里給出了實例。

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

• NewRelic APM

• 
  

• Application Insights

• 
  

• AppDynamics

• 
  

• Stackify

　基礎設施監(jiān)控工具

　　基礎設施監(jiān)控工具在主機層面采集指標，這可更完整地反映性能。這些指標是在硬件和軟件層面采集的。

• DataDog

• 
  

• OpServer - Open Source

　輕量級分析工具

　　輕量級分析工具為特定Web請求提供了高層次的指標，并在開發(fā)人員瀏覽Web頁面時就可提供實時反饋。這些工具可用于所有的環(huán)境類型中（包括開發(fā)環(huán)境、QA驗證、模擬環(huán)境、生產環(huán)境等），因此非常適合于對特定頁面性能的快速評估。

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

　　在開發(fā)環(huán)境中，輕量級分析工具對當前正編寫的代碼提供了實時反饋。這對于發(fā)現(xiàn)N+1或響應時間慢等問題是非常有用的，因為響應時間總是顯示在頁面的一角上。

• 開源的MiniProfiler

• 
  

• 開源的Glimpse

　用性能計數器填補空白

　　Windows系統(tǒng)中的性能計數器（Performance counter）提供了硬件和軟件層次上不同方面的指標。監(jiān)控工具通常以性能計數器為報告方式，例如CPU和內存占用情況。但是通常會缺失一些有用的計數器，例如垃圾回收時間等。最切實可行的入門方法是使用基本列表并在迭代中添加必要的相關計數器。此外，使用perfmon對性能計數器進行實時地采集和可視化是可行的。在很多情況下，將用戶定制指標或插件與APM工具進行集成也是可行的。

　SQL工具

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

　　在提供下列數據情況下，可以發(fā)現(xiàn)一些類型的問題并可對性能進行改進：

• 在一個或數個查詢上存在過度的吞吐量；

• 
  

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

• 
  

• 可被緩存的高吞吐量查詢。

　　SQL監(jiān)控工具包括：

• RedGate SQL Monitor

• 
  

• SQLSentry Performance Advisor

　其它的持久系統(tǒng)

　　所有子系統(tǒng)都需要在某種程度上進行監(jiān)控。對于低吞吐量或非關鍵的系統(tǒng)，簡單的數據采集和可視化即足矣。在此外的情況下則需要更加高級的、專業(yè)的監(jiān)控。

　代碼分析工具

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

　　分析工具：

• Redgate Ants

• 
  

• JetBrains dotTrace

　內存分析工具

　　內存監(jiān)控和垃圾回收指標有助于潛在問題的檢測。但這些指標在顯示了存在問題的同時，通常并未給出問題的所在。如果需要隊內存和垃圾回收問題進行深入地探究，內存分析工具就可派上用場。

　　分析工具：

• JetBrains dotMemory

• 
  

• RedGate Ants Memory Profiler

　用戶端分析工具

　　性能問題也可能來自于前端。當前這個問題十分常見，因為以JavaScript主導的單頁應用的大量涌現(xiàn)。所有的主流瀏覽器都已嵌入了諸如代碼分析和內存分析這樣的工具。顯示事件和請求的序列的工具有利于一眼就確定問題是源于前端還是后端。

　　工具：Tools:

• Google Chrome Timeline

• 
  

• Firefox

　頁面分析工具

　　高層次客戶端工具為發(fā)現(xiàn)并解決性能問題的提供了便利著手點。這些工具可以針對響應時間問題的產生根源提供高層次的視圖，并給出一些相應的建議。例如Google的PageSpeed Insights就是這樣的一個免費工具。

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

以上是“如何監(jiān)控ASP.NET性能”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業(yè)資訊頻道！