前端和雲端性能分析工具分析報告

　　性能測試工具的主要做用是經過模擬生產環境中的真實業務操做，對被測試系統實行壓力負載測試，監視被 測試系統在不一樣業務、不一樣壓力性能下的性能表現。找出潛在的性能瓶頸進行分析、優化。
　　client與server至關於兩我的，經過信息來進行交流。

由於初次見面很差意思直接交流。與是找來了中間傳話人，client把信息告訴給傳話人，由傳話人來轉達給server。那麼server反饋的信息也由傳話人轉達給client。通常性能測試工具都需要錄製或編寫client行爲腳本。

這樣傳達人就有了client的行爲能力，從而假扮client來欺騙server，與之進行通訊。有了client行爲了傳達人可以進行自我複製。從而變出N多個傳達人對server進通訊。—這個傳達人的行爲和能力也就是性能測試工具的基本特質。（忽然以爲性能工具像第三者插足，而且是可以自我複製瘋狂變態的第三者，哈哈！）
　對於眼下流行的性能測試工具，他們的基本工做原理都是一致的。

在client經過多線程或多進程模擬虛擬用戶訪問，對server端施加壓力。而後在過程當中監控和收集性能數據。

性能測試工具應該具有的特質：
一、工具自己佔用系統資源少，可擴展性好，可用性強。
二、能模擬真實業務事務操做，在併發時能真正產生業務壓力。

（這一點是核心）
三、對壓力測試結果能很是好地進行性能分析，高速找出被測試系統的瓶頸。
四、測試腳本的反覆性強。

先後端對照：
Web應用的基礎是超文本傳輸協議（HTTP）和超文本標記語言（HTML）。HTTP協議自己是一種面向非鏈接的協議，HTML語言則是一種用於製做超文本文檔資料的簡單標記語言。
　　對於一個頁面而言，「請求」和「返回數據」均可能是屢次發生的。這個我在《在作性能測試以前需要知道什麼》一文中舉了一個簡單的樣例來解說。

由於HTTP對瀏覽器下載資源併發請求數量、Cache等方面都進行定義和限制，以及瀏覽器對於HTML的處理過程。全然可以說。用戶因此感覺的響應時間中的至關大的一部分並不全然取決於應用的後臺處理所需要的時間，而取決於web應用的前端。

在yahoo中，到少50個團隊經過純粹的前端性能相關的技巧，將終於用戶的響應時間下降了25%以上。
　　HTTP是一個屬於應用層的面向對象的協議。用於傳送WWW方式的數據，採用請求\響應模型，client向server發送一個請求，請求頭包括請求的方法、URI、協議版本號。以及包括請求修飾符、客戶信息和內容的類似於HTML的消息結構。

server以一個狀態行做爲響應。響應的內容包括消息協議的版本號。成功或者錯誤編碼加上包括server信息。實體元信息以及可能的實體內容。
　　 HTML是一種用於製做超文本文檔資料的簡單標記語言，用HTML編寫的超文本文檔可以獨立於各類操做系統平臺。從誕生開始，HTML語言就一直被用於描寫敘述web頁面格式設計。使用HTML語言描寫敘述的文件需要經過WWW瀏覽器顯示效果。

如下用兩種方式來對照較兩種測試響應時間的區別
　　Apache benchmark 簡稱ab ，是很是有名又小巧的壓力測試工具。

　　下載安裝apache web server 安裝或解壓以後，在bin\文件夾下有個ab運行文件。
　　打開運行–cmd 打開命令提示符。定位到bin\文件夾下。
基本用法：
ab -c [併發用戶數] -n [發送請求數] [被測試頁面的URL]
設置一個用戶一個請求，對百度首頁加壓：
http://www.baidu.com/

從上表中咱們可以看到請求的總字節數爲8024字節；響應時間爲0.173 秒，也就是如下顯示的173.010毫秒。

---

Firebug很是有名的debug工具，firefox瀏覽器最得意的集成工具。
在firefox瀏覽菜單條「工具」—加入組件—搜索firebug下載安裝從新啓動瀏覽器。
相同對百度首頁的訪問：
http://www.baidu.com/

從上面圖中看到請求的大小爲10KB；響應時間1.4秒。清楚的發現這數據可以遠遠大於ab工具所獲得的數據。細緻觀察發現，firebug給出的數據，訪問 http://www.baidu.com/ 網址時，client（瀏覽器）和應用之間的數據交互並不是1次，而是5次。
　　咱們再分析當中的一個請求，firefox給出的的圖形中，有紅色和藍色兩種顏色的線條。藍色表示到此刻發生了DOMContentLoaded事件。紅色線條表示onload事件被觸發。DOMContentLoaded事件W3C推薦的標準事件。它發生在頁面的DOM樹建成時，而onload則發生在頁面所有的資源（圖片文件、CSS文件、js文件等）都被下載完畢後。

　　從上圖的右下角，咱們會獲得兩個響應時間，1.41秒是onload事件被觸發的時間。前面的1.4秒則是頁面的所有請求都返回所需要的總時間。那麼哪一個時間纔是用戶感覺到的響應時間呢？準確的說，兩個都不是。

用戶的感覺是個不肯定的狀態。取決於頁面自己的類型以及呈現手段。假設某頁面僅爲用戶提供閱讀信息，一旦頁面上開始出現可供閱讀的內容，用戶就開始閱讀了。

那麼，用戶以爲響應時間就是發出請求到頁面上出現可閱讀信息。假設頁面存在大量的交互內容。需要用戶填寫或在頁面上進行拖拽等操做，在這樣的狀況下。僅僅有當頁面的所有元素都被下正確的呈現出來。所有的js文件都已經運行完畢後，用戶纔會感覺到這個頁面已經就緒。
　　Web前端性能的研究並不是爲了準確地獲得一個響應時間數據，實際上，依據friebug圖表的結果，web性能一部分取決於webserver和應用server（創建鏈接，下載鏈接），別一部分取決於瀏覽器的實現機制、web頁面上的js的運行等。取決於webserver和應用server的響應時間與server的負載、壓力等相關；而取決於瀏覽器實現機制與js文件運行所需要的時間則差點兒與server端的負載和壓力無關。

那麼web端的響應時間也是總響應時間的一部分，那麼有必要web端的性能進行了解。
　　那麼前端性能這麼見效。爲何還要去作後端性能測試呢？由於他們關注點不一樣，前端性能關注單個用戶的感覺。

後端性能關注是不少其它用戶訪問系統時，server能更穩定、更快的處理用戶發來的請求。一個強大的後臺是前臺的基礎。

前端:

性能測試一直是 Web 應用中很是受關注的部分。眼下大多數人對性能的關注還主要集中在服務端，大部分人在說到「性能測試」的時候。都會把重點放到服務端的性能測試和調優，也就是經過各類方法找到服務端的性能瓶頸並嘗試對其進行調優。但實際上。對於 web 應用來講，除了考慮服務端在足夠短的時間內返回頁面數據以外，還可以從頁面 前端 的角度來考慮性能測試和性能調優。

在線站點類：
WebPageTest
說明：
在線的站點性能評測站點，地址http://www.webpagetest.org/
補充：
事實上這站點也是個開源項目，因此支持本身搭建一個內部的測試站點

獨立程序類：
DynaTrace Ajax Edition
說明：
基於IE，firefox的插件。對於FF需要版本號支持，需要獨立安裝文件（50多M）。其可支持到函數級的度量分析，此外其它工具能支持的功能這個工具都支持的。

這個工具可以跟蹤JavaScript從運行開始。通過本地的XMLHttpRequest、發送網絡請求，再到請求返回的全過程。

什麼是 dynaTrace Ajax
隨着 jQuery、Dojo、YUI 等框架的興起讓構建 Web2.0 應用更加easy。但隨之帶來的定位等應用問題也愈來愈難，尤爲是與性能相關的。

dynaTrace Ajax Edition 是一個強大的底層追蹤、前端性能分析工具，該工具不只可以記錄瀏覽器的請求在網絡中的傳輸時間、前端頁面的渲染時間、DOM 方法運行時間以及 JavaScript 代碼的解析和運行時間，還可以跟蹤 JavaScript 從運行開始。通過本地的 XMLHttpRequest、發送網絡請求、再到請求返回的全過程。
dynaTrace Ajax 眼下有兩個版本號，免費版和商業版，它們之間的區別可查看 版本號比較，本文主要是針對免費版本號的介紹。

在 3.0 以前的版本號僅僅支持運行在 IE 瀏覽器下，包括 IE六、IE七、IE8， 在 3.0 Beta 版以後可同一時候支持在 IE 和 Firefox 瀏覽器上的性能跟蹤。

應用案例分析
如下記錄的結果是以咱們眼下正開發的一個實際項目（IBM Docs）中的一個案例 - 在 Web 中打開一個 PPT 文檔。依據 dynaTrace 收集的信息來分析存在的性能問題。
Performance Report( 性能報告視圖 )
從 Cockpit 面板中打開 Performance Report 視圖。如圖所看到的：
圖. 性能報告

性能報告視圖中記錄了所有訪問的網頁的具體信息，從這個視圖當中咱們可以獲得如下信息：
加載頁面所消耗的時間 ：OnLoad Time[ms] 顯示從頁面開始加載到瀏覽器派發 onload 事件所經歷的時間。Total Load Time[ms] 顯示頁面所有 load 完總共消耗的時間
JavaScript 運行時間 ：On Client[ms] 經過 JS API 或庫運行的所有 JavaScript 函數所消耗的總時間
網絡請求花了多長時間： 從 Remark 中可看到總共同擁有多少請求數。當中有多少 XHR 請求等信息
server端所消耗時間： On Server[ms] 指client發出的所有請求在server過了多長時間開始響應所消耗的總時間
從右下方的各個面板中可以獲得總體的性能分析報告（更具體的信息可查看 Cockpit 面板中的對應節點），好比：
NetWork 中可看出有多少資源是從瀏覽器緩存中讀取的，有多少的 HTTP 轉發請求消耗了沒必要要的網絡傳輸時間。合併同一個 domain 中的 CSS、JS 的請求可節省多長網絡傳輸時間。

TimeLine 中顯示了頁面的生命週期：該圖反映了頁面進程中網絡資源下載。JavaScript 運行，頁面發生渲染，CPU 使用狀況。以及發生了哪些事件。好比：Load 事件、XMLHttpRequest 等信息。

在個人樣例中。如下內容引發了個人注意：
網絡耗時較長，請求數目太多：總共同擁有 896 網絡請求。當中有 300+ 個 request 是對圖片的請求。300+ 個是從 cache 中對相同圖片的讀取。
JavaScript 運行時間總耗時 22 秒： 從右下方的 JavaScript/Ajax(A) 報告中可看出有一個 OnLoad 的事件就消耗了總共 13 秒 的時間，雙擊可從右邊窗體看出它的先後調用棧信息。
Server 端處理總共花了 20 秒 的時間 : 這說明 Server 端也可能存在性能問題，可推薦你們使用 Performance Inspector工具去分析 Server 端的性能問題，這裏再也不詳述。

Remark 欄還顯示了頁面總共發出了 23 個 XMLHttpRequest 請求: 這可以從時間軸的 event 行中找出發生的時間點。

下一節將會針對這些問題進行更具體的討論。
Timeline( 時間軸視圖） - 頁面生命週期
時間軸視圖可以經過雙擊 Cockpit 面板中的 TimeLine 節點打開或者在 Performance Report 中經過在某個 URL 上點擊右鍵。選擇「DrillDown-TimeLine 」打開。依據 性能報告視圖 打開耗時比較長的 URL 的 TimeLine, 經過工具欄或右鍵菜單。可以打開不少其它選項，比方內容類型和 JavaScript 觸發器的顏色值，或者顯示不少其它事件，比方鼠標移動、點擊和鍵盤事件。打開本案例的時間軸視圖，如圖 所看到的：
圖. 時間軸

在此視圖下。咱們可觀測到：
CPU 佔用率可顯示 JavaScript 的運行致使瀏覽器佔用 CPU 的時間
JavaScript 運行所佔用的時間：從上圖中觀察到右邊藍色塊的那一段耗時比較長。鼠標懸停在這段上可以看到是由於 load event on 觸發的。耗時將近 13 秒 的時間
瀏覽器 Rendering，懸停上去可發現大部分是由於在計算 layout 所需要的時間，通常在 IE 上面運行相對會比較明顯
網絡請求並行下載耗時，一方面來自請求的數目太多，當中一個比較明顯的就是有一個 XMLHttpRequest 花在 Server 的處理耗時將近 7 秒的時間
Event 軸顯示了鼠標點擊事件，XMLHttpRequest 事件和 OnLoad 事件
放大右邊網絡請求時間比較長的部分（在個人樣例中，從 16s 到 29s 時間片 ), 經過在開始處點擊鼠標左鍵拖拽到結束位置鬆開鼠標拖拽。視圖將放大到如下截圖中顯示的時間片上。例如如下圖 所看到的 :
圖. 放大時間軸

經過放大的時間片右鍵選擇「Drill Down to Timeframe e」進入 PurePath 視圖。顯示當前所放大的時間片上所有的活動。

dynaTrace Ajax 是前端的軟件開發project師和性能分析師的很是實用且重要的工具。經過該工具的不斷更新，功能的不斷強大，所支持的瀏覽器的不斷添加以及與持續集成工具相結合，這樣就可以更easy、更早、更頻繁地發現應用程序在不一樣瀏覽器上的性能問題。

後端：
無論什麼評測工具，基本的技術都是利用線程技術模仿和虛擬用戶，在這裏基本的難點在於測試腳本的編寫，每種工具使用的腳本都不同。但是大多數工具都提供錄製功能就算是不會編碼的測試人員相同可以測試。

衆所周知，server是整個網絡系統和計算平臺的核心。不少重要的數據都保存在server上。很是多網絡服務都在server上運行，所以server性能的好壞決定了整個應用系統的性能。
現在市面上不一樣品牌、不一樣種類的server有很是多種。用戶在選購時，如何從紛繁的型號中選擇出所需要的，適合於本身應用的server產品，僅僅從配置上判別是不夠的。最好可以經過實際測試來篩選。而各類的評測軟件有很是多種，你應該選擇哪一個軟件測試？如下就介紹一些較典型的測試工具：
（一）server整機系統性能測試工具
一臺server系統的性能可以依照處理器、內存、存儲、網絡幾部分來劃分，而針對不一樣的應用，可能會對某些部分的性能要求高一些。

（二）針對應用的測試工具

　　隨着web應用的增多，server應用解決方式中以Web爲核心的應用也愈來愈多，很是多公司各類應用的架構都以web應用爲主。通常的web測試和以往的應用程序的測試的側重點不全然相同，在基本功能已經經過測試後。就要進行重要的系統性能測試了。系統的性能是一個很是大的概念。覆蓋面很是普遍。對一個軟件系統而言包括運行效率、資源佔用率、穩定性、安全性、兼容性、可靠性等等，如下重點從負載壓力方面來介紹server系統性能的測試。

系統的負載和壓力需要採用負載測試工具進行。虛擬必定數量的用戶來測試系統的表現。看是否知足預期的設計指標要求。負載測試的目標是測試當負載逐漸添加時，系統組成部分的對應輸出項，好比經過量、響應時間、CPU負載、內存使用等如何決定系統的性能。好比穩定性和響應等。

負載測試通常使用工具完畢。有Loadrunner，Webload，QALoad等，基本的內容都是編寫出測試腳本。腳本中通常包括用戶常用的功能，而後運行，得出報告。使用壓力測試工具對webserver進行壓力測試。

測試可以幫助找到一些大型的問題，如死機、崩損、內存泄漏等。由於有些存在內存泄漏問題的程序，在運行一兩次時可能不會出現故障，但是假設運行了成千上萬次，內存泄漏得愈來愈多。就會致使系統崩滑。

ab是Apache超文本傳輸協議(HTTP)的性能測試工具。

其設計意圖是描繪當前所安裝的Apache的運行性能， 主要是顯示你安裝的Apache每秒可以處理多少個請求。

ab [ -A auth-username:password ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -v verbosity] [ -V ] [ -w ] [ -x

-attributes ] [ -X proxy[:port] ] [ -y -attributes ] [ -z

-attributes ] [http://]hostname[:port]/path

選項

-A auth-username:password
對server提供BASIC認證信任。 username與password由一個:隔開。並以base64編碼形式發送。

無論server是否需要(即, 是否發送了401認證需求代碼)，此字符串都會被髮送。
-c concurrency
一次產生的請求個數。默認是一次一個。
-C cookie-name=value
對請求附加一個Cookie:行。 其典型形式是name=value的一個參數對。 此參數可以反覆。
-d
不顯示」percentage served within XX [ms] table」的消息(爲曾經的版本號提供支持)。

-e csv-file
產生一個以逗號分隔的(CSV)文件， 當中包括了處理每個對應百分比的請求所需要(從1%到100%)的對應百分比的(以微妙爲單位)時間。 由於這樣的格式已經「二進制化」。因此比’gnuplot’格式更實用。

-g gnuplot-file
把所有測試結果寫入一個’gnuplot’或者TSV (以Tab分隔的)文件。 此文件可以方便地導入到Gnuplot, IDL, Mathematica, Igor甚至Excel中。 當中的第一行爲標題。

-h
顯示用法。
-H custom-header
對請求附加額外的頭信息。

此參數的典型形式是一個有效的頭信息行，當中包括了以冒號分隔的字段和值的對 (如, 「Accept-Encoding: zip/zop;8bit」).
-i
運行HEAD請求，而不是GET。

-k
啓用HTTP KeepAlive功能。即, 在一個HTTP會話中運行多個請求。 默認時，不啓用KeepAlive功能.
-n requests
在測試會話中所運行的請求個數。 默認時。僅運行一個請求，但一般其結果不具備表明意義。
-p POST-file
包括了需要POST的數據的文件.
-P proxy-auth-username:password
對一箇中轉代理提供BASIC認證信任。 username與password由一個:隔開，並以base64編碼形式發送。 無論server是否需要(即, 是否發送了401認證需求代碼)。此字符串都會被髮送。

-q
假設處理的請求數大於150， ab每處理大約10%或者100個請求時，會在stderr輸出一個進度計數。

此-q標記可以抑制這些信息。
-s
用於編譯中(ab -h會顯示相關信息)使用了SSL的受保護的https， 而不是http協議的時候。

此功能是實驗性的，也是很是簡陋的。最好不要用。
-S
不顯示中值和標準背離值， 而且在均值和中值爲標準背離值的1到2倍時，也不顯示警告或出錯信息。 默認時。會顯示 最小值/均值/最大值等數值。

(爲曾經的版本號提供支持).
-t timelimit
測試所進行的最大秒數。

其內部隱含值是-n 50000。 它可以使對server的測試限制在一個固定的總時間之內。默認時，沒有時間限制。
-T content-type
POST數據所使用的Content-type頭信息。

-v verbosity
設置顯示信息的具體程度 - 4或更大值會顯示頭信息。 3或更大值可以顯示響應代碼(404, 200等), 2或更大值可以顯示警告和其它信息。
-V
顯示版本號號並退出。
-w
以HTML表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。
-x

-attributes
設置 屬性的字符串。 此屬性被填入

tar zxvf http_load-12mar2006.tar.gz

cd http_load-12mar2006

make && make install

命令格式：http_load -p 併發訪問進程數 -s 訪問時間 需要訪問的URL文件
參數事實上可以自由組合，參數之間的選擇並無什麼限制。

比方你寫成http_load -parallel 5 -seconds
300 urls.txt也是可以的。咱們把參數給你們簡單說明一下。
-parallel 簡寫-p ：含義是併發的用戶進程數。
-fetches 簡寫-f ：含義是總計的訪問次數
-rate 簡寫-p ：含義是每秒的訪問頻率
-seconds簡寫-s ：含義是總計的訪問時間
準備URL文件：urllist.txt，文件格式是每行一個URL，URL最好超過50－100個測試效果比較好.文件格式
例如如下：
http://www.vpser.net/uncategorized/choose-vps.html
http://www.vpser.net/vps-cp/hypervm-tutorial.html
http://www.vpser.net/coupons/diavps-april-coupons.html
http://www.vpser.net/security/vps-backup-web-mysql.html
好比：
http_load -p 30 -s 60 urllist.txt
參數了解了，咱們來看運行一條命令來看看它的返回結果
命令：% ./http_load -rate 5 -seconds 10 urls說明運行了一個持續時間10秒的測試，每秒的頻率爲5。

49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274
fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first
-response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 – 49
結果分析：
1．49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
說明在上面的測試中運行了49個請求，最大的併發進程數是2。總計傳輸的數據是289884bytes。運行的時間是10.0148秒
2．5916 mean bytes/connection說明每一鏈接平均傳輸的數據量289884/49=5916
3．4.89274 fetches/sec, 28945.5 bytes/sec
說明每秒的響應請求爲4.89274，每秒傳遞的數據爲28945.5 bytes/sec
4．msecs/connect: 28.8932 mean, 44.243 max, 24.488 min說明每鏈接的平均響應時間是28.8932 msecs
。最大的響應時間44.243 msecs，最小的響應時間24.488 msecs
5．msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
六、HTTP response codes: code 200 – 49 說明打開響應頁面的類型，假設403的類型過多，那可能
要注意是否系統遇到了瓶頸。

特殊說明： 測試結果中基本的指標是 fetches/sec、msecs/connect 這個選項。即server每秒可以響應的查詢次數， 用這個指標來衡量性能。彷佛比 apache的ab準確率要高一些。也更有說服力一些。 Qpt-每秒響應用戶數和response time，每鏈接響應用戶時間。 測試的結果主要也是看這兩個值。固然僅有這兩個指標並不能完畢對性能的分析，咱們還需要對server的 cpu、men進行分析。才幹得出結論