關(guā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è)置。
• 代碼分析工具為程序性能給出了最為詳盡的視圖。
• 輕量級分析工具給出了網(wǎng)頁性能的實時視圖，可用在開發(fā)環(huán)境和生產(chǎn)環(huán)境中。

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

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

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

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

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

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

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

• JavaScript響應(yīng)慢；
• 資源加載中的產(chǎn)生了阻塞；
• 用戶端存在代理；
• DNS問題；
• ISP或網(wǎng)絡(luò)問題；
• 交換機(jī)和路由器；
• 負(fù)載均衡器；
• 應(yīng)用代碼（包括第三方軟件庫）；
• HTTP服務(wù)器（例如有時是ASP.net或IIS）；
• 第三方服務(wù)，例如：支付服務(wù)提供商、地圖服務(wù)提供商等；
• 子系統(tǒng)，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。

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

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

• 客戶端，服務(wù)器端或是兩者之間的某處？
• 響應(yīng)慢的JavaScript、渲染或是資源阻塞？
• 負(fù)載均衡器、Web服務(wù)器、任一子系統(tǒng)或是第三方軟件？

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

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

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

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

　架構(gòu)問題

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

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

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

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

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

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

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

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

　　APM可用于：

• 對Web應(yīng)用性能做整體可視化；
• 對特定的Web請求性能進(jìn)行可視化；
• 在Web應(yīng)用性能變差時或者多個錯誤出現(xiàn)時，自動發(fā)送告警；
• 在業(yè)務(wù)量大時，對應(yīng)用的響應(yīng)方式進(jìn)行驗證。

　　在這里給出了實例。

　　下面并非詳盡地列出了支持對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

　輕量級分析工具

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

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

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

• 開源的MiniProfiler
• 開源的Glimpse

　用性能計數(shù)器填補空白

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

　SQL工具

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

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

• 在一個或數(shù)個查詢上存在過度的吞吐量；
• 過度的CPU占用，這暗示了查詢問題的存在或者是索引的缺失；
• 可被緩存的高吞吐量查詢。

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

• RedGate SQL Monitor
• SQLSentry Performance Advisor

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

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

　代碼分析工具

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

　　分析工具：

• Redgate Ants
• JetBrains dotTrace

　內(nèi)存分析工具

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

　　分析工具：

• JetBrains dotMemory
• RedGate Ants Memory Profiler

　用戶端分析工具

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

　　工具：Tools:

• Google Chrome Timeline
• Firefox

　頁面分析工具

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

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

標(biāo)簽： dns Google http服務(wù)器 isp web服務(wù)器 代碼 防火墻 服務(wù)器 服務(wù)器端 數(shù)據(jù)庫 搜索 網(wǎng)絡(luò)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。