爲了闡明準確甄別性能問題的重要性，下面列舉了一些致使Web應用響應慢的可能問題排查點：php
- JavaScript響應慢；
- 資源加載中的產生了阻塞；
- 用戶端存在代理；
- DNS問題；
- ISP或網絡問題；
- 交換機和路由器；
- 負載均衡器；
- 應用代碼（包括第三方軟件庫）；
- HTTP服務器（例若有時是ASP.net或IIS）；
- 第三方服務，例如：支付服務提供商、地圖服務提供商等；
- 子系統，包括：SQL Server、Redis、Elasticsearch、Rabbit MQ等。
還能夠羅列出更多的性能問題排查點，這取決於需處理系統的複雜度和規模。在如此之多的系統組件均可影響性能優化問題的狀況下，如何才能確診性能問題呢？答案歸納爲一個詞：數據。你須要來自於每一個系統組件的、相關且有意義的數據。對於Web應用響應慢的問題，數據能夠證實每一個系統組件是對問題是有影響的仍是徹底無關的。前端
數據在手，就能夠開始從上述列表中按你的思路去抽取問題排查點進行分析，這相似於在排序樹中進行查找。每次在樹中向下走一層，就越接近於性能問題的細節和實質，依次甄別性能問題是否存在於：web
- 客戶端，服務器端或是二者之間的某處？
- 響應慢的JavaScript、渲染或是資源阻塞？
- 負載均衡器、Web服務器、任一子系統或是第三方軟件？
在這樣樹中逐層下行時，性能問題會變得愈來愈清晰。對於每一個層次上的問題排查點，定位性能問題所需的數據必需要與對應的問題精度相匹配。這時有必要去使用性能分析工具或SQL執行計劃這樣的工具。sql
例如在一個Web請求中，假定須要100毫秒的服務器處理時間和5秒的SQL查詢時間。即便你能夠將服務器處理時間優化到低於1毫秒，可是這對總體響應時間的改進很小，也就是從5.1秒變成5秒。改進SQL處理所需的5秒時間是潛在收益最大的優化。chrome
架構問題
這種逐層釐清優化問題所在的自頂向下方法，對於侷限在單一頁面中的優化問題具備很好的效果。那麼應用於跨越多個頁面的優化問題上時效果又如何呢？例如，一些頁面所存在的間歇性地打開慢問題，是因爲子系統跟不上總體工做節奏，或是因爲系統中存在某個再次重啓可能就沒法繼續工做的老舊網絡交換機。數據庫
這種狀況下，側重於應用的監控方法顯示出它的侷限性所在。這須要更多的軟件層面和硬件層面上的指標，用於對系統中的每一個組件進行評估。後端
在硬件層面，首先所能想到就是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就是這樣的一個免費工具。
系統性能相關的因素和工具的數量是很是之多，這看上去彷佛十分複雜。可是它們能夠用一個詞進行歸納：數據。對系統有一個清晰的和準確的視圖，這使得推理性能問題成爲可能。這也使你能夠在現場學習如何去解決性能問題，由於性能指標和圖表將會引導你去發現究竟是什麼影響了系統性能。