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

創(chuàng)新互聯(lián)堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的白云鄂網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

　關(guān)鍵要點(diǎn)：

• 只有與應(yīng)用指標(biāo)相關(guān)聯(lián)，基礎(chǔ)設(shè)施指標(biāo)才能最大發(fā)揮作用。

• 高效性能優(yōu)化的關(guān)鍵在于性能數(shù)據(jù)。

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

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

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

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

　數(shù)據(jù)采集與使用的基本原理

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

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

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

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

為了闡明準(zhǔn)確甄別性能問題的重要性，下面列舉了一些導(dǎo)致Web應(yīng)用響應(yīng)慢的可能問題排查點(diǎn)：

• JavaScript響應(yīng)慢；

• 資源加載中的產(chǎn)生了阻塞；

• 用戶端存在代理；

• DNS問題；

• ISP或網(wǎng)絡(luò)問題；

• 交換機(jī)和路由器；

• 負(fù)載均衡器；

• 應(yīng)用代碼（包括第三方軟件庫）；

• HTTP服務(wù)器（例如有時(shí)是ASP.net或IIS）；

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

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

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

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

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

• 響應(yīng)慢的JavaScript、渲染或是資源阻塞？

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

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

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

無論一個(gè)任務(wù)改進(jìn)的程度如何，該任務(wù)中沒有從改進(jìn)中受益的部分限制了理論上的任務(wù)加速。

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

　架構(gòu)問題

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

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

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

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

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

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

　應(yīng)用性能管理（Application Performance Management，APM）工具

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

APM可用于：

• 對(duì)Web應(yīng)用性能做整體可視化；

• 對(duì)特定的Web請(qǐng)求性能進(jìn)行可視化；

• 在Web應(yīng)用性能變差時(shí)或者多個(gè)錯(cuò)誤出現(xiàn)時(shí)，自動(dòng)發(fā)送告警；

• 在業(yè)務(wù)量大時(shí)，對(duì)應(yīng)用的響應(yīng)方式進(jìn)行驗(yàn)證。

在這里給出了實(shí)例。

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

• NewRelic APM

• Application Insights

• AppDynamics

• Stackify

　基礎(chǔ)設(shè)施監(jiān)控工具

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

• DataDog

• OpServer - Open Source

　輕量級(jí)分析工具

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

與相應(yīng)的具有完全功能的分析工具相比，輕量級(jí)分析工具的本質(zhì)差異在于它們并非附屬于過程，這意味著在使用輕量級(jí)分析工具時(shí)無需操心它們所產(chǎn)生的開銷。

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

• 開源的MiniProfiler

• 開源的Glimpse

　用性能計(jì)數(shù)器填補(bǔ)空白

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

　SQL工具

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

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

• 在一個(gè)或數(shù)個(gè)查詢上存在過度的吞吐量；

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

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

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

• RedGate SQL Monitor

• SQLSentry Performance Advisor

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

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

　代碼分析工具

當(dāng)已確診某個(gè)特定頁面或代碼段檢測(cè)是響應(yīng)慢的，代碼分析工具可為性能問題鑒定提供最詳盡的視圖。代碼分析工具還可為數(shù)據(jù)庫查詢和Web請(qǐng)求這樣的外部調(diào)用提供了精準(zhǔn)視圖。

分析工具：

• Redgate Ants

• JetBrains dotTrace

　內(nèi)存分析工具

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

分析工具：

• JetBrains dotMemory

• RedGate Ants Memory Profiler

　用戶端分析工具

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

工具：Tools:

• Google Chrome Timeline

• Firefox

　頁面分析工具

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

系統(tǒng)性能相關(guān)的因素和工具的數(shù)量是非常之多，這看上去似乎十分復(fù)雜。但是它們可以用一個(gè)詞進(jìn)行概括：數(shù)據(jù)。對(duì)系統(tǒng)有一個(gè)清晰的和準(zhǔn)確的視圖，這使得推理性能問題成為可能。這也使你可以在現(xiàn)場學(xué)習(xí)如何去解決性能問題，因?yàn)樾阅苤笜?biāo)和圖表將會(huì)引導(dǎo)你去發(fā)現(xiàn)到底是什么影響了系統(tǒng)性能。

以上是“如何監(jiān)控ASP.NET性能”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！