只有與應用指標相關聯，基礎設施指標才能最大發揮作用。
# 高效能效能優化的關鍵在於效能數據。
# 一些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佔用率這樣的系統指標進行視覺化。
APM工具提供資料收集、資料儲存和資料視覺化這些基礎操作。通常是由代理負責採集資料並將資料傳送給資料存儲，並使用Web介面以集中在Web請求上的儀錶板方式對資料進行視覺化。
APM可用來：
# 對Web應用程式效能做整體視覺化；
# 對特定的Web請求效能進行視覺化；
# 當Web應用效能變差時或多個錯誤出現時，自動傳送警告；
在業務量大時，對應用程式的回應方式進行驗證。
在這裡給了一個實例。
下面並非詳盡地列出了支援對ASP.NET和IIS開箱即用的APM工具清單：
NewRelic APM
# Application Insights
# AppDynamics
# Stackify
基礎設施監控工具在主機層級採集指標，這可更完整地反映效能。這些指標是在硬體和軟體層面收集的。
DataDog
# OpServer - Open Source
# 輕量級分析工具為特定Web請求提供了高層次的指標，並在開發人員瀏覽Web頁面時就可提供即時回饋。這些工具可用於所有的環境類型（包括開發環境、QA驗證、模擬環境、生產環境等），因此非常適合於特定頁面效能的快速評估。
與相應的具有完全功能的分析工具相比，輕量級分析工具的本質差異在於它們並非附屬於過程，這意味著在使用輕量級分析工具時無需操心它們所產生的開銷。
在開發環境中，輕量級分析工具對目前正編寫的程式碼提供了即時回饋。這對於發現N+1或回應時間慢等問題是非常有用的，因為回應時間總是顯示在頁面的角落。
開源的MiniProfiler
# 開源的Glimpse
# Windows系統中的效能計數器（Performance counter）提供了硬體和軟體層次上不同方面的指標。監控工具通常以效能計數器為報告方式，例如CPU和記憶體佔用情況。但是通常會缺少一些有用的計數器，例如垃圾回收時間等。最切實可行的入門方法是使用基本列表並在迭代中添加必要的相關計數器。此外，使用perfmon對效能計數器進行即時地擷取和視覺化是可行的。在許多情況下，將使用者自訂指標或外掛程式與APM工具進行整合也是可行的。
由於在許多應用中普遍地使用了資料庫，持久層（即SQL資料庫）常常成為效能的瓶頸。用於SQL監控的專業工具可提供資源使用指標，以及一些特定的指標，例如等待時間、每秒編譯次數等，在這裡僅列舉幾個。
在提供下列資料情況下，可以發現一些類型的問題並可對效能進行改進：
在一個或數個查詢上存在過度的吞吐量；
過度的CPU佔用，這暗示了查詢問題的存在或索引的缺失；
SQL監控工具包括：
# RedGate SQL Monitor
所有子系統都需要在某種程度上進行監控。對於低吞吐量或非關鍵的系統，簡單的資料收集和視覺化即足矣。在此外的情況下則需要更進階的、專業的監控。
分析工具：
分析工具：
工具：Tools:
#### Google Chrome Timeline############################ Firefox############# 頁面分析工具###### 高階客戶端工具為發現並解決效能問題的提供了便利著手點。這些工具可以針對回應時間問題的產生根源提供高層次的視圖，並給予一些相應的建議。例如Google的PageSpeed Insights就是這樣的一個免費工具。 ###### 系統性能相關的因素和工具的數量是非常之多，這看起來似乎十分複雜。但是它們可以用一個字來概括：數據。對系統有一個清晰的和準確的視圖，這使得推理效能問題成為可能。這也使你可以在現場學習如何解決效能問題，因為效能指標和圖表將會引導你去發現到底是什麼影響了系統效能。 ###以上是ASP.NET效能監控與優化入門的詳細內容。更多資訊請關注PHP中文網其他相關文章！
