<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    qileilove

    blog已經(jīng)轉(zhuǎn)移至github,大家請訪問 http://qaseven.github.io/

    【譯】如何精確判斷最終用戶響應(yīng)時間過長的原因

    譯者:原始文章有點性能測試工具軟文的感覺,畢竟文章來源于某工具官方博客。高手請略過。

      對于我這種新手,此文還是給我?guī)硪恍@喜,從上到下地,從表象到根源地,定位他們遇到性能問題-響應(yīng)時間過長-的根本原因,有具體的步驟,思考和判斷依據(jù),這就是一個比較不錯性能測試分析實例。可以更清楚看到性能測試如何分析定位,可以學(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ā)團隊進行了一個任務(wù),驗證生產(chǎn)環(huán)境的系統(tǒng)是否能在現(xiàn)有的硬件基礎(chǔ)上處理10倍于目前的負(fù)載。為了將網(wǎng)站在高負(fù)載下可能的崩潰影響降到最低,我們決定在周日下午進行第一輪測試。在運行測試之前,我們給運維團隊提了一個醒:他們可能在這次兩小時的期間觀察到明顯的負(fù)載變化,從而可能影響到運行在同一環(huán)境下的其他應(yīng)用程序。

      在測試過程中,運維團隊和開發(fā)團隊一起監(jiān)控實時性能數(shù)據(jù),當(dāng)達到一定的負(fù)載水平后,我們看到最終用戶的響應(yīng)時間和耗盡資源。在本次測試中非常有趣的是,開發(fā)團隊和運維團隊都看著相同的數(shù)據(jù),但是卻從不同的角度去審視這些結(jié)果。然而,他們都是依賴于最近才公布的Compuware的PureStack技術(shù),這是——整合dynaTrace和PurePath——的第一個解決方案,顯示出在高負(fù)載下生產(chǎn)環(huán)境的硬件是如何影響到關(guān)鍵業(yè)務(wù)應(yīng)用程序的性能。

      上下文為運維團隊和開發(fā)團隊的數(shù)據(jù)之間架起橋梁:這張圖片顯示"橫向"事務(wù)以及"縱向"層面的熱點區(qū)域(BridgingtheGapbetweenOpsandAppsDatabyaddingContext:OnepicturethatshowstheHotspotsof"Horizontal"Transactionaswellasthe"Vertical"Stack.)。

      在我們的場景中表現(xiàn)不佳的根本原因-一個運行著Web和應(yīng)用程序服務(wù)的主服務(wù)器的CPU被耗盡-從而導(dǎo)致達不到我們的負(fù)載目標(biāo)。事實證明,這個問題是跟硬件設(shè)備和應(yīng)用程序都有關(guān)系(ThisturnedouttobebothanITprovisioningandanapplicationproblem)。讓我解釋一下團隊的步驟以及他們是如何得出他們的行動項列表,以便改善目前的系統(tǒng)性能,以便在第二輪測試中得到更好的結(jié)果。

      第1步:監(jiān)控和識別硬件健康狀況

      運維團隊希望能夠看著他們的服務(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ù)載測試達到了頂峰時,他們看向服務(wù)器的狀態(tài)時,顯示出來卻是,他們有2臺機器正出現(xiàn)了異常:

      我們的社區(qū)網(wǎng)站核心服務(wù)器出現(xiàn)CPU相關(guān)的問題,并影響到另一運行在這臺服務(wù)器上的應(yīng)用程序。

      步驟2:哪些運行中的應(yīng)用程序被真正影響到了?

      單擊受影響的程序選項卡,它會顯示受影響的機器上所有運行的應(yīng)用程序,以及目前受影響的應(yīng)用程序:

      增加的負(fù)載不僅影響到社區(qū)網(wǎng)站,而且也影響到我們支持網(wǎng)站

      這次負(fù)載測試已經(jīng)讓我們明白:如果我們希望未來的社區(qū)網(wǎng)站能夠承擔(dān)更高的負(fù)載,那我們可能需要移動支持網(wǎng)站到其他的機器,以避免不必要的影響。 
    當(dāng)兩個團隊孤立檢查,運維導(dǎo)向的監(jiān)測是不會有這個的結(jié)論(Whenexaminedindependently,operations-orientedmonitoringwouldnotbethattelling.)。但是,當(dāng)它被放到具體的上下文中,并涉及到關(guān)聯(lián)的數(shù)據(jù)(最終用戶響應(yīng)時間,用戶體驗,...),這對開發(fā)團隊來說是非常重要的,兩個團隊將獲得更多的靈感和視角。這是一個良好的開端,但仍然還有很多需要了解的。

      步驟3:哪些關(guān)鍵事務(wù)被真正影響到了?

      點擊社區(qū)應(yīng)用程序的鏈接,它會顯示實際受硬件狀態(tài)影響的事務(wù)和頁面,但仍然存在著兩個關(guān)鍵的卻又懸而未決的問題:

      這些事務(wù),是否是我們成功運行的關(guān)鍵?

      這些事務(wù)和個人用戶受性能問題影響后,有多嚴(yán)重的后果?

      自動基線告訴我們,社區(qū)網(wǎng)站主要頁面的響應(yīng)時間受到明顯的的性能影響。也包括我們的首頁,這是我們最有價值的一個頁面。

      步驟4:可視化受硬件問題影響的事務(wù)流

      事務(wù)流圖表是一個令人滿意的方式,能使得運維團隊和開發(fā)團隊達到一個基本的共識,并根據(jù)其完整的上下文查看關(guān)鍵的數(shù)據(jù)。它能顯示涉及到的應(yīng)用層,正在運行的物理機器和虛擬機器,以及哪里是熱點區(qū)域。

     

      運維團隊和開發(fā)團隊有相同的概要圖表,告訴他們無論是在"橫向"事務(wù)和"縱向"層面的熱點區(qū)域。

      我們知道,我們的網(wǎng)頁內(nèi)容非常"豐富"(圖像,JavaScript和CSS),高達80%的事務(wù)時間花費在瀏覽器上。看到熱點區(qū)域這樣的表現(xiàn),現(xiàn)在整體頁面加載時間下降到50%,我們馬上就知道更多的事務(wù)時間已經(jīng)轉(zhuǎn)移到新的熱點區(qū)域:服務(wù)器端。好消息是,數(shù)據(jù)庫是沒有問題的(只用了1%的響應(yīng)時間),整個性能熱點區(qū)域似乎轉(zhuǎn)到Web和應(yīng)用程序服務(wù)器,它們都運行在同一臺機器上-即那臺存在CPU問題的機器。

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

      點擊主機健康圖表(HostHealthDashboard),它會顯示了那個特定的服務(wù)器出了什么問題:

      運維團隊立即看到了CPU的消耗主要來自于一個Java應(yīng)用服務(wù)器。網(wǎng)絡(luò),磁盤和頁面錯誤在一些某些特定的時間也都存在不尋常的波動。


    第6步:進程健康圖表顯示應(yīng)用程序服務(wù)器上響應(yīng)緩慢

      我們可以看到,這臺機器上的兩個主要進程是IIS(Web服務(wù)器)和Tomcat(應(yīng)用程序服務(wù)器)。再進一步看看,隨著時間的推移,他們具體的表現(xiàn)情況:

      我們并不是沒有足夠的工作線程。傳輸速率是相當(dāng)平緩。這就說明,Web服務(wù)器正在等待應(yīng)用服務(wù)器的響應(yīng)。

      它表明應(yīng)用程序服務(wù)器的CPU被耗盡。負(fù)載測試工具發(fā)送的持續(xù)請求在排隊等待,因為服務(wù)器無法及時處理掉這些請求。實際上已處理的事務(wù)數(shù)量在下降。

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

      現(xiàn)在我們開發(fā)團隊非常有興趣搞清楚到底是什么在消耗著CPU,以及是否我們可以在應(yīng)用程序代碼里面修復(fù),或者是否只是我們需要更多的CPU:

      熱點區(qū)域顯示應(yīng)用程序的兩層都消耗CPU比較多。讓我們進一步深入。



     我們有些相當(dāng)復(fù)雜的頁面(包含大量Confluencemacros)導(dǎo)致大量的CPU占用。

      缺少資源和身份驗證問題導(dǎo)致了這些異常。

      運維和開發(fā)團隊現(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)到"縱向"的硬件層面信息,這就很容易讓兩個團隊達到一個共識,并規(guī)劃影響最小的修復(fù)的優(yōu)先級。

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

      當(dāng)應(yīng)用程序?qū)ζ渌绦蛟斐韶?fù)面影響時,部署我們的關(guān)鍵應(yīng)用程序到其他的機器上。

      優(yōu)化我們的頁面生成方式,以便降低CPU使用率。

      為虛擬機分配更多的CPU,以便能夠處理更多的負(fù)載。

    版權(quán)聲明:本文出自 在劫錄  的51Testing軟件測試博客: http://www.51testing.com/?166582

    原創(chuàng)作品,轉(zhuǎn)載時請務(wù)必以超鏈接形式標(biāo)明本文原始出處、作者信息和本聲明,否則將追究法律責(zé)任。


    posted on 2013-09-13 11:53 順其自然EVO 閱讀(401) 評論(0)  編輯  收藏 所屬分類: web 前端性能測試

    <2013年9月>
    25262728293031
    1234567
    891011121314
    15161718192021
    22232425262728
    293012345

    導(dǎo)航

    統(tǒng)計

    常用鏈接

    留言簿(55)

    隨筆分類

    隨筆檔案

    文章分類

    文章檔案

    搜索

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 亚洲日本精品一区二区| 免费播放在线日本感人片| 亚洲视频一区在线观看| 亚洲色偷偷综合亚洲AV伊人| 台湾一级毛片永久免费| 国内精品免费在线观看| 一级中文字幕免费乱码专区 | 国产精品免费看久久久| a级毛片免费观看在线| 在线亚洲v日韩v| 亚洲偷自拍另类图片二区| 亚洲国产美女在线观看| 亚洲AV乱码久久精品蜜桃| 在线亚洲精品自拍| 亚洲性日韩精品一区二区三区 | 亚洲一级视频在线观看| 亚洲视频国产精品| 91亚洲国产成人久久精品网站| 国产亚洲精久久久久久无码77777| 狼友av永久网站免费观看| 欧美在线看片A免费观看| 成人免费午夜无码视频| 巨波霸乳在线永久免费视频| 国产精成人品日日拍夜夜免费| 国产区在线免费观看| 亚洲精品黄色视频在线观看免费资源 | 亚洲精品午夜视频| 亚洲成aⅴ人片在线影院八| 久久久久亚洲AV无码专区体验| 久久久久亚洲av无码专区蜜芽| 亚洲成AV人片在线观看无码 | 1000部无遮挡拍拍拍免费视频观看 | 日韩免费视频播播| 国产男女猛烈无遮挡免费视频网站 | 亚洲国产精品久久久久久| 亚洲AV无码不卡在线播放| 无码乱人伦一区二区亚洲一| 综合自拍亚洲综合图不卡区| 亚洲午夜久久久久久尤物| 亚洲av永久无码精品三区在线4| 亚洲成a人片毛片在线|