關鍵要點：
- 只有與應用指標相關聯，基礎設施指標才能最大發揮作用。
- 高效性能優化的關鍵在於性能數據。
- 一些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工具清單：
基礎設施監控工具
基礎設施監控工具在主機層面採集指標，這可更完整地反映性能。這些指標是在硬件和軟件層面採集的。
輕量級分析工具
輕量級分析工具爲特定Web請求提供了高層次的指標，並在開發人員瀏覽Web頁面時就可提供實時反饋。這些工具可用於所有的環境類型中（包括開發環境、QA驗證、模擬環境、生產環境等），因此非常適合於對特定頁面性能的快速評估。
與相應的具有完全功能的分析工具相比，輕量級分析工具的本質差異在於它們並非附屬於過程，這意味着在使用輕量級分析工具時無需操心它們所產生的開銷。
在開發環境中，輕量級分析工具對當前正編寫的代碼提供了實時反饋。這對於發現N+1或響應時間慢等問題是非常有用的，因爲響應時間總是顯示在頁面的一角上。
用性能計數器填補空白
Windows系統中的性能計數器（Performance counter）提供了硬件和軟件層次上不同方面的指標。監控工具通常以性能計數器爲報告方式，例如CPU和內存佔用情況。但是通常會缺失一些有用的計數器，例如垃圾回收時間等。最切實可行的入門方法是使用基本列表並在迭代中添加必要的相關計數器。此外，使用perfmon對性能計數器進行實時地採集和可視化是可行的。在很多情況下，將用戶定製指標或插件與APM工具進行集成也是可行的。
SQL工具
由於在很多應用中普遍地使用了數據庫，持久層（即SQL數據庫）常常成爲性能的瓶頸。用於SQL監控的專業工具可提供資源使用指標，以及一些特定的指標，例如等待時間、每秒編譯次數等，在這裏僅列舉幾個。
在提供下列數據情況下，可以發現一些類型的問題並可對性能進行改進：
- 在一個或數個查詢上存在過度的吞吐量；
- 過度的CPU佔用，這暗示了查詢問題的存在或者是索引的缺失；
- 可被緩存的高吞吐量查詢。
SQL監控工具包括：
其它的持久系統
所有子系統都需要在某種程度上進行監控。對於低吞吐量或非關鍵的系統，簡單的數據採集和可視化即足矣。在此外的情況下則需要更加高級的、專業的監控。
代碼分析工具
當已確診某個特定頁面或代碼段檢測是響應慢的，代碼分析工具可爲性能問題鑑定提供最詳盡的視圖。代碼分析工具還可爲數據庫查詢和Web請求這樣的外部調用提供了精準視圖。
分析工具：
內存分析工具
內存監控和垃圾回收指標有助於潛在問題的檢測。但這些指標在顯示了存在問題的同時，通常並未給出問題的所在。如果需要隊內存和垃圾回收問題進行深入地探究，內存分析工具就可派上用場。
分析工具：
用戶端分析工具
性能問題也可能來自於前端。當前這個問題十分常見，因爲以JavaScript主導的單頁應用的大量涌現。所有的主流瀏覽器都已嵌入了諸如代碼分析和內存分析這樣的工具。顯示事件和請求的序列的工具有利於一眼就確定問題是源於前端還是後端。
工具：Tools:
頁面分析工具
高層次客戶端工具爲發現並解決性能問題的提供了便利着手點。這些工具可以針對響應時間問題的產生根源提供高層次的視圖，並給出一些相應的建議。例如Google的PageSpeed Insights就是這樣的一個免費工具。
系統性能相關的因素和工具的數量是非常之多，這看上去似乎十分複雜。但是它們可以用一個詞進行概括：數據。對系統有一個清晰的和準確的視圖，這使得推理性能問題成爲可能。這也使你可以在現場學習如何去解決性能問題，因爲性能指標和圖表將會引導你去發現到底是什麼影響了系統性能。