譯者：原始文章有點(diǎn)性能測試工具軟文的感覺，畢竟文章來源于某工具官方博客。高手請略過。
對于我這種新手，此文還是給我?guī)硪恍@喜，從上到下地，從表象到根源地，定位他們遇到性能問題-響應(yīng)時間過長-的根本原因，有具體的步驟，思考和判斷依據(jù)，這就是一個比較不錯性能測試分析實(shí)例。可以更清楚看到性能測試如何分析定位，可以學(xué)習(xí)其思路。故分享之。
原文連接:http://apmblog.compuware.com/2013/06/04/how-to-accurately-identify-impact-of-system-issues-on-end-user-response-time/
以下為正文
我們希望檢測下我們社區(qū)網(wǎng)站的負(fù)載能力，所以我們開發(fā)團(tuán)隊(duì)進(jìn)行了一個任務(wù)，驗(yàn)證生產(chǎn)環(huán)境的系統(tǒng)是否能在現(xiàn)有的硬件基礎(chǔ)上處理10倍于目前的負(fù)載。為了將網(wǎng)站在高負(fù)載下可能的崩潰影響降到最低，我們決定在周日下午進(jìn)行第一輪測試。在運(yùn)行測試之前，我們給運(yùn)維團(tuán)隊(duì)提了一個醒：他們可能在這次兩小時的期間觀察到明顯的負(fù)載變化，從而可能影響到運(yùn)行在同一環(huán)境下的其他應(yīng)用程序。
在測試過程中，運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)一起監(jiān)控實(shí)時性能數(shù)據(jù)，當(dāng)達(dá)到一定的負(fù)載水平后，我們看到最終用戶的響應(yīng)時間和耗盡資源。在本次測試中非常有趣的是，開發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)都看著相同的數(shù)據(jù)，但是卻從不同的角度去審視這些結(jié)果。然而，他們都是依賴于最近才公布的Compuware的PureStack技術(shù)，這是——整合dynaTrace和PurePath——的第一個解決方案，顯示出在高負(fù)載下生產(chǎn)環(huán)境的硬件是如何影響到關(guān)鍵業(yè)務(wù)應(yīng)用程序的性能。
上下文為運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)的數(shù)據(jù)之間架起橋梁：這張圖片顯示"橫向"事務(wù)以及"縱向"層面的熱點(diǎn)區(qū)域(BridgingtheGapbetweenOpsandAppsDatabyaddingContext:OnepicturethatshowstheHotspotsof"Horizontal"Transactionaswellasthe"Vertical"Stack.)。
在我們的場景中表現(xiàn)不佳的根本原因-一個運(yùn)行著Web和應(yīng)用程序服務(wù)的主服務(wù)器的CPU被耗盡-從而導(dǎo)致達(dá)不到我們的負(fù)載目標(biāo)。事實(shí)證明，這個問題是跟硬件設(shè)備和應(yīng)用程序都有關(guān)系(ThisturnedouttobebothanITprovisioningandanapplicationproblem)。讓我解釋一下團(tuán)隊(duì)的步驟以及他們是如何得出他們的行動項(xiàng)列表，以便改善目前的系統(tǒng)性能，以便在第二輪測試中得到更好的結(jié)果。
第1步：監(jiān)控和識別硬件健康狀況
運(yùn)維團(tuán)隊(duì)希望能夠看著他們的服務(wù)器列表，而所有關(guān)鍵指標(biāo)（CPU，內(nèi)存，網(wǎng)絡(luò)，磁盤等）都能很快地呈現(xiàn)出綠色狀態(tài)(OperationsTeamslikehavingtheabilitytolookattheirlistofserversandquicklyseethatallcriticalindicators(CPU,Memory,Network,Disk,etc)aregreen)。但是，當(dāng)我們的負(fù)載測試達(dá)到了頂峰時，他們看向服務(wù)器的狀態(tài)時，顯示出來卻是，他們有2臺機(jī)器正出現(xiàn)了異常：
我們的社區(qū)網(wǎng)站核心服務(wù)器出現(xiàn)CPU相關(guān)的問題，并影響到另一運(yùn)行在這臺服務(wù)器上的應(yīng)用程序。
步驟2：哪些運(yùn)行中的應(yīng)用程序被真正影響到了？
單擊受影響的程序選項(xiàng)卡，它會顯示受影響的機(jī)器上所有運(yùn)行的應(yīng)用程序，以及目前受影響的應(yīng)用程序：
增加的負(fù)載不僅影響到社區(qū)網(wǎng)站，而且也影響到我們支持網(wǎng)站
這次負(fù)載測試已經(jīng)讓我們明白：如果我們希望未來的社區(qū)網(wǎng)站能夠承擔(dān)更高的負(fù)載，那我們可能需要移動支持網(wǎng)站到其他的機(jī)器，以避免不必要的影響。
當(dāng)兩個團(tuán)隊(duì)孤立檢查，運(yùn)維導(dǎo)向的監(jiān)測是不會有這個的結(jié)論(Whenexaminedindependently,operations-orientedmonitoringwouldnotbethattelling.)。但是，當(dāng)它被放到具體的上下文中，并涉及到關(guān)聯(lián)的數(shù)據(jù)（最終用戶響應(yīng)時間，用戶體驗(yàn)，...），這對開發(fā)團(tuán)隊(duì)來說是非常重要的，兩個團(tuán)隊(duì)將獲得更多的靈感和視角。這是一個良好的開端，但仍然還有很多需要了解的。
步驟3：哪些關(guān)鍵事務(wù)被真正影響到了？
點(diǎn)擊社區(qū)應(yīng)用程序的鏈接，它會顯示實(shí)際受硬件狀態(tài)影響的事務(wù)和頁面，但仍然存在著兩個關(guān)鍵的卻又懸而未決的問題：
這些事務(wù)，是否是我們成功運(yùn)行的關(guān)鍵？
這些事務(wù)和個人用戶受性能問題影響后，有多嚴(yán)重的后果？
自動基線告訴我們，社區(qū)網(wǎng)站主要頁面的響應(yīng)時間受到明顯的的性能影響。也包括我們的首頁，這是我們最有價值的一個頁面。
步驟4：可視化受硬件問題影響的事務(wù)流
事務(wù)流圖表是一個令人滿意的方式，能使得運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)達(dá)到一個基本的共識，并根據(jù)其完整的上下文查看關(guān)鍵的數(shù)據(jù)。它能顯示涉及到的應(yīng)用層，正在運(yùn)行的物理機(jī)器和虛擬機(jī)器，以及哪里是熱點(diǎn)區(qū)域。
運(yùn)維團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)有相同的概要圖表，告訴他們無論是在"橫向"事務(wù)和"縱向"層面的熱點(diǎn)區(qū)域。
我們知道，我們的網(wǎng)頁內(nèi)容非常"豐富"（圖像，JavaScript和CSS），高達(dá)80％的事務(wù)時間花費(fèi)在瀏覽器上。看到熱點(diǎn)區(qū)域這樣的表現(xiàn)，現(xiàn)在整體頁面加載時間下降到50％，我們馬上就知道更多的事務(wù)時間已經(jīng)轉(zhuǎn)移到新的熱點(diǎn)區(qū)域：服務(wù)器端。好消息是，數(shù)據(jù)庫是沒有問題的（只用了1％的響應(yīng)時間），整個性能熱點(diǎn)區(qū)域似乎轉(zhuǎn)到Web和應(yīng)用程序服務(wù)器，它們都運(yùn)行在同一臺機(jī)器上-即那臺存在CPU問題的機(jī)器。
第5步：精確定位存在問題的機(jī)器的健康問題
點(diǎn)擊主機(jī)健康圖表(HostHealthDashboard)，它會顯示了那個特定的服務(wù)器出了什么問題：
運(yùn)維團(tuán)隊(duì)立即看到了CPU的消耗主要來自于一個Java應(yīng)用服務(wù)器。網(wǎng)絡(luò)，磁盤和頁面錯誤在一些某些特定的時間也都存在不尋常的波動。
第6步：進(jìn)程健康圖表顯示應(yīng)用程序服務(wù)器上響應(yīng)緩慢
我們可以看到，這臺機(jī)器上的兩個主要進(jìn)程是IIS（Web服務(wù)器）和Tomcat（應(yīng)用程序服務(wù)器）。再進(jìn)一步看看，隨著時間的推移，他們具體的表現(xiàn)情況：
我們并不是沒有足夠的工作線程。傳輸速率是相當(dāng)平緩。這就說明，Web服務(wù)器正在等待應(yīng)用服務(wù)器的響應(yīng)。
它表明應(yīng)用程序服務(wù)器的CPU被耗盡。負(fù)載測試工具發(fā)送的持續(xù)請求在排隊(duì)等待，因?yàn)榉?wù)器無法及時處理掉這些請求。實(shí)際上已處理的事務(wù)數(shù)量在下降。
第7步：精確定位CPU的大量消耗
現(xiàn)在我們開發(fā)團(tuán)隊(duì)非常有興趣搞清楚到底是什么在消耗著CPU，以及是否我們可以在應(yīng)用程序代碼里面修復(fù)，或者是否只是我們需要更多的CPU：
熱點(diǎn)區(qū)域顯示應(yīng)用程序的兩層都消耗CPU比較多。讓我們進(jìn)一步深入。
我們有些相當(dāng)復(fù)雜的頁面（包含大量Confluencemacros）導(dǎo)致大量的CPU占用。
缺少資源和身份驗(yàn)證問題導(dǎo)致了這些異常。
運(yùn)維和開發(fā)團(tuán)隊(duì)現(xiàn)在可以輕松地劃分處理硬件和應(yīng)用程序問題的優(yōu)先級
所以如前所述，上下文是關(guān)鍵。但這些數(shù)據(jù)不是輕而易舉就能獲得的-上下文依賴于智能關(guān)聯(lián)的能力，使所有相關(guān)的數(shù)據(jù)組成一個連貫的故事。當(dāng)"橫向"的事務(wù)數(shù)據(jù)（最終用戶響應(yīng)時間的分析）關(guān)聯(lián)到"縱向"的硬件層面信息，這就很容易讓兩個團(tuán)隊(duì)達(dá)到一個共識，并規(guī)劃影響最小的修復(fù)的優(yōu)先級。
這次實(shí)驗(yàn)使我們能夠確定以下幾個行動項(xiàng)：
當(dāng)應(yīng)用程序?qū)ζ渌绦蛟斐韶?fù)面影響時，部署我們的關(guān)鍵應(yīng)用程序到其他的機(jī)器上。
優(yōu)化我們的頁面生成方式，以便降低CPU使用率。
為虛擬機(jī)分配更多的CPU，以便能夠處理更多的負(fù)載。
版權(quán)聲明：本文出自 在劫錄 的51Testing軟件測試博客： http://www.51testing.com/?166582
原創(chuàng)作品，轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明，否則將追究法律責(zé)任。