關(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提供了開(kāi)箱即用的支持，這樣入門(mén)使用ASP.NET僅需最小限度的初始設(shè)置。
• 代碼分析工具為程序性能給出了最為詳盡的視圖。
• 輕量級(jí)分析工具給出了網(wǎng)頁(yè)性能的實(shí)時(shí)視圖，可用在開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境中。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　架構(gòu)問(wèn)題

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

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

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

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

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

　　底線(xiàn)就是，為評(píng)估系統(tǒng)的健康度，CPU、內(nèi)存和磁盤(pán)等全系統(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)求上的儀表盤(pán)方式對(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開(kāi)箱即用的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)，并在開(kāi)發(fā)人員瀏覽Web頁(yè)面時(shí)就可提供實(shí)時(shí)反饋。這些工具可用于所有的環(huán)境類(lèi)型中（包括開(kāi)發(fā)環(huán)境、QA驗(yàn)證、模擬環(huán)境、生產(chǎn)環(huán)境等），因此非常適合于對(duì)特定頁(yè)面性能的快速評(píng)估。

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

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

• 開(kāi)源的MiniProfiler
• 開(kāi)源的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í)可行的入門(mén)方法是使用基本列表并在迭代中添加必要的相關(guān)計(jì)數(shù)器。此外，使用perfmon對(duì)性能計(jì)數(shù)器進(jìn)行實(shí)時(shí)地采集和可視化是可行的。在很多情況下，將用戶(hù)定制指標(biāo)或插件與APM工具進(jìn)行集成也是可行的。

　SQL工具

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

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

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

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

• RedGate SQL Monitor
• SQLSentry Performance Advisor

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

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

　代碼分析工具

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

　　分析工具：

• Redgate Ants
• JetBrains dotTrace

　內(nèi)存分析工具

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

　　分析工具：

• JetBrains dotMemory
• RedGate Ants Memory Profiler

　用戶(hù)端分析工具

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

　　工具：Tools:

• Google Chrome Timeline
• Firefox

　頁(yè)面分析工具

　　高層次客戶(hù)端工具為發(fā)現(xiàn)并解決性能問(wèn)題的提供了便利著手點(diǎn)。這些工具可以針對(duì)響應(yīng)時(shí)間問(wèn)題的產(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)確的視圖，這使得推理性能問(wèn)題成為可能。這也使你可以在現(xiàn)場(chǎng)學(xué)習(xí)如何去解決性能問(wèn)題，因?yàn)樾阅苤笜?biāo)和圖表將會(huì)引導(dǎo)你去發(fā)現(xiàn)到底是什么影響了系統(tǒng)性能。

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

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