譯者：原始文章有點效能測試工具軟文的感覺，畢竟文章來源於某工具官方部落格。高手請略過。
對於我這種新手，此文還是給我帶來一些驚喜，從上到下地，從表象到根源地，定位他們遇到效能問題-響應時間過長-的根本原因，有具體的步驟，思考和判斷依據，這就是一個比較不錯效能測試分析例項。可以更清楚看到效能測試如何分析定位，可以學習其思路。故分享之。

原文連線: http://apmblog.compuware.com/2013/06/04/how-to-accurately-identify-impact-of-system-issues-on-end-user-response-time/

 
以下為正文

我們希望檢測下我們社群網站的負載能力，所以我們開發團隊進行了一個任務，驗證生產環境的系統是否能在現有的硬體基礎上處理10倍於目前的負載。為了將網站在高負載下可能的崩潰影響降到最低，我們決定在週日下午進行第一輪測試。在執行測試之前，我們給運維團隊提了一個醒：他們可能在這次兩小時的期間觀察到明顯的負載變化，從而可能影響到執行在同一環境下的其他應用程式。

在測試過程中，運維團隊和開發團隊一起監控實時效能資料，當達到一定的負載水平後，我們看到終端使用者的響應時間和耗盡資源。在本次測試中非常有趣的是，開發團隊和運維團隊都看著相同的資料，但是卻從不同的角度去審視這些結果。然而，他們都是依賴於最近才公佈的Compuware的PureStack技術 ，這是——整合dynaTrace和PurePath——的第一個解決方案，顯示出在高負載下生產環境的硬體是如何影響到關鍵業務應用程式的效能。

上下文為運維團隊和開發團隊的資料之間架起橋樑：這張圖片顯示"橫向"事務以及"縱向"層面的熱點區域(Bridging the Gap between Ops and Apps Data by adding Context: One picture that shows the Hotspots of "Horizontal" Transaction as well as the "Vertical" Stack.)。

在我們的場景中表現不佳的根本原因 - 一個執行著Web和應用程式服務的主伺服器的CPU被耗盡 - 從而導致達不到我們的負載目標。事實證明，這個問題是跟硬體裝置和應用程式都有關係(This turned out to be both an IT provisioning and an application problem)。讓我解釋一下團隊的步驟以及他們是如何得出他們的行動項列表，以便改善目前的系統性能，以便在第二輪測試中得到更好的結果。

第1步：監控和識別硬體健康狀況

運維團隊希望能夠看著他們的伺服器列表，而所有關鍵指標（CPU，記憶體，網路，磁碟等）都能很快地呈現出綠色狀態(Operations Teams like having the ability to look at their list of servers and quickly see that all critical indicators (CPU, Memory, Network, Disk, etc) are green)。但是，當我們的負載測試達到了頂峰時，他們看向伺服器的狀態時，顯示出來卻是，他們有2臺機器正出現了異常：

我們的社群網站核心伺服器出現CPU相關的問題，並影響到另一執行在這臺伺服器上的應用程式。

步驟2：哪些執行中的應用程式被真正影響到了？

單擊受影響的程式 選項卡，它會顯示受影響的機器上所有執行的應用程式，以及目前受影響的應用程式：

增加的負載不僅影響到社群網站，而且也影響到我們支援網站

這次負載測試已經讓我們明白：如果我們希望未來的社群網站能夠承擔更高的負載，那我們可能需要移動支援網站到其他的機器，以避免不必要的影響。

當兩個團隊孤立檢查，運維導向的監測是不會有這個的結論(When examined independently, operations-oriented monitoring would not be that telling.)。但是，當它被放到具體的上下文中，並涉及到關聯的資料（終端使用者響應時間，使用者體驗，...），這對開發團隊來說是非常重要的，兩個團隊將獲得更多的靈感和視角。這是一個良好的開端，但仍然還有很多需要了解的。

步驟3：哪些關鍵事務被真正影響到了？

點選社群應用程式的連結，它會顯示實際受硬體狀態影響的事務和頁面，但仍然存在著兩個關鍵的卻又懸而未決的問題：

• 這些事務，是否是我們成功執行的關鍵？
• 這些事務和個人使用者受效能問題影響後，有多嚴重的後果？

自動基線告訴我們，社群網站主要頁面的響應時間受到明顯的的效能影響。也包括我們的首頁，這是我們最有價值的一個頁面。

步驟4：視覺化受硬體問題影響的事務流

事務流圖表是一個令人滿意的方式，能使得運維團隊和開發團隊達到一個基本的共識，並根據其完整的上下文檢視關鍵的資料。它能顯示涉及到的應用層，正在執行的物理機器和虛擬機器器，以及哪裡是熱點區域。

運維團隊和開發團隊有相同的概要圖表，告訴他們無論是在"橫向"事務和"縱向"層面的熱點區域。

我們知道，我們的網頁內容非常"豐富"（影象，JavaScript和CSS），高達80％的事務時間花費在瀏覽器上。看到熱點區域這樣的表現，現在整體頁面載入時間下降到50％，我們馬上就知道更多的事務時間已經轉移到新的熱點區域：伺服器端。好訊息是，資料庫是沒有問題的（只用了1％的響應時間），整個效能熱點區域似乎轉到Web和應用程式伺服器，它們都執行在同一臺機器上 - 即那臺存在CPU問題的機器。

第5步：精確定位存在問題的機器的健康問題

點選主機健康圖表(Host Health Dashboard)，它會顯示了那個特定的伺服器出了什麼問題：

運維團隊立即看到了CPU的消耗主要來自於一個Java應用伺服器。網路，磁碟和頁面錯誤在一些某些特定的時間也都存在不尋常的波動。

第6步：程序健康圖表顯示應用程式伺服器上響應緩慢

我們可以看到，這臺機器上的兩個主要程序是IIS（Web伺服器）和Tomcat（應用程式伺服器）。再進一步看看，隨著時間的推移，他們具體的表現情況：

我們並不是沒有足夠的工作執行緒。傳輸速率是相當平緩。這就說明，Web伺服器正在等待應用伺服器的響應。

它表明應用程式伺服器的CPU被耗盡。負載測試工具傳送的持續請求在排隊等待，因為伺服器無法及時處理掉這些請求。實際上已處理的事務數量在下降。

第7步：精確定位CPU的大量消耗

現在我們開發團隊非常有興趣搞清楚到底是什麼在消耗著CPU，以及是否我們可以在應用程式程式碼裡面修復，或者是否只是我們需要更多的CPU：

熱點區域顯示應用程式的兩層都消耗CPU比較多。讓我們進一步深入。

我們有些相當複雜的頁面（包含大量Confluence macros）導致大量的CPU佔用。

缺少資源和身份驗證問題導致了這些異常。

運維和開發團隊現在可以輕鬆地劃分處理硬體和應用程式問題的優先順序

所以如前所述，上下文是關鍵。但這些資料不是輕而易舉就能獲得的 - 上下文依賴於智慧關聯的能力，使所有相關的資料組成一個連貫的故事。當"橫向"的事務資料（終端使用者響應時間的分析）關聯到"縱向"的硬體層面資訊，這就很容易讓兩個團隊達到一個共識，並規劃影響最小的修復的優先順序。

這次實驗使我們能夠確定以下幾個行動項：

• 當應用程式對其他程式造成負面影響時，部署我們的關鍵應用程式到其他的機器上。
• 優化我們的頁面生成方式，以便降低CPU使用率。
• 為虛擬機器分配更多的CPU，以便能夠處理更多的負載。