（一）在Vusers（虛擬用戶狀態）中

　　1.Running Vusers（負載過程中的虛擬用戶運行情況）

　　說明——系統形成負載的過程，隨著時間的推移，虛擬用戶數量是如何變化的，描述為（用戶在幾分鐘左右到達了組在峰值多少個虛擬用戶，負載的生成是大約每分鐘增加幾個用戶，峰值負載持續為幾分幾秒）。

　　2.Rendezvous（負載過程中集合點下的虛擬用戶數）

　　說明——腳本中一般要設置集合點才會產生并發，隨著時間的推移各個時間點上并發用戶的數目，方便我們了解并發用戶數的變化情況。描述（剛開始的幾分鐘內，負載的并發用戶都是幾個，而后面變化為幾個用戶并發）。

　　（二）在Transactions（事務）中

　　這里給出了所有和事務相關的數據統計，方便了解被測試系統業務處理的響應時間和吞吐量。

　　1.Average Transaction Response Time（平均事務響應時間）

　　說明——反映隨著時間的變化事務響應時間的變化情況，時間越小說明處理的速度越快。如果和前面的用戶負載生成圖合并在一起看，就可以發現用戶負載增加對系統事務響應時間的影響規律。描述（看到響應時間是如何增長的，隨著時間的推移響應時間逐漸變長，并且在不到多少時間的時候突然出現響應時間大幅下降的情況）另外事務的響應時間也不應該超過用戶的最大接受范圍，否則會出現系統響應過慢的問題。

　　2.Transactions per Second（每秒事務數）

　　說明——數據反映了系統在同一時間內能處理業務的最大能力，這個數據越高，說明系統處理能力越強。描述（看到系統的TPS隨著時間的變化逐漸變大，而在不到多少分鐘的時候系統每秒可以處理多少個事務。這里的最高值并不一定代表系統的最大處理能力，TPS會受到負載的影響，也會隨著負載的增加而逐漸增加，當系統進入繁忙期后，TPS會有所下降。而在幾分鐘以后開始出現少量的失敗事務）

　　3.Transaction Summary（事務概要說明）

　　說明——通過的事務數越多，說明系統的處理能力越強；失敗的事務越少，說明系統越可靠。描述（對于注冊操作一共有對少次操作成功，有幾次失敗。可以開率結合前面的每秒錯誤數進一步分析為什么會出現幾個注冊錯誤，以及錯誤發生的時間和該時間產生錯誤的原因）

　　4.Transaction Performance Summary（事務性能概要）

　　說明——給出事務的平均時間、最大時間、最小時間柱狀圖，方便分析事務響應時間的情況。描述（看到這個事務最大時間為多少S，最小時間為多少S，平均時間為多少S。柱狀圖的落差越小說明響應時間的波動較小，那么說明系統不夠穩定。）

　　5.Transaction Response Time Under Load（在用戶負載下事務響應時間）

　　說明——在負載用戶增長的過程中響應時間的變化情況，起始這張圖也是將Vusers和Average Transaction Response Time圖做了一個Correlate Merge得到的，該圖的線條越平穩，說明系統越穩定。描述（看到負載逐漸增加到幾個用戶時，事務的響應時間基本沒有變化，而用戶增加到幾個開始，隨著用戶負載的增加響應時間也有較大的波動）

　　6.Transaction Response Time（Percentile）（事務響應時間的百分比）

　　說明——有多少比例的事務發生在某個時間內，也可以發現響應時間的分布規律，數據越平穩說明響應時間變化越小。描述（看到百分幾%的事務是在幾秒內）

　　7.Transaction Response Time （Distribution）（每個時間段上的事務數）

　　說明——在每個時間段上的事務個數，響應時間較小的分類下的事務數越多越好。描述（看到在所有的事務中，有多少個事務的響應時間最接近幾秒，而有幾個事務的響應時間最接近幾秒）

　　（三）在Web Resources（網頁資源信息）中

　　當Controller的Run Time Setting中Preferences下的Generated Web performance graphs選項處于開啟狀態時，該圖表才會出現。

　　1.Hits per Second（每秒點擊數）

　　說明——每秒點擊數提供了當前負載重對系統所產生的點擊量記錄。每一次點擊相當于對服務器發出了一次請求，一般點擊數會隨著負載的增加而增加，該數據越大越好。描述（隨著時間的增加，每秒點擊數在上升，最高達到了多少次/s）。

　　2.Throughput（帶寬使用）

　　說明——當前系統負載下所使用的帶寬，該數據越小說明系統的貸款依賴越小，通過這個數據能確定是否出現了網絡帶寬的瓶頸。描述（得到醉倒的帶寬峰值是多少B，遠遠低于100Mb的局域網帶寬上限，所以系統不存在帶寬瓶頸）。

　　3.HTTP Responses per Second（每秒HTTP響應數）

　　說明——每秒鐘服務器返回各種狀態的數目，該數值一般和每秒點擊量相同。點擊量是指客戶端發出的請求數，而HTTP響應數是指服務器返回的響應數。如果服務器返回的響應數小于發出的請求數，那么說明服務器無法應答超出負載的連接請求。描述（最高峰時服務器每秒能返回接近多少個HTTP _ 200 OK的狀態）。

　　4.Connections Per Second（每秒連接數）

　　說明——兩種不同狀態的連接數，即中斷的連接和新建的連接，方便用戶了解當前每秒對服務器產生連接的數量。描述（隨著時間的推移，系統的連接數逐步上升，最高達到每秒幾個連接）同時的連接數越多，說明服務器的連接池越大，當連接數隨著負載上升而停止上升時，說明系統的連接池已滿，無法連接更多的用戶，通常這個時候服務器會返回504錯誤。可以通過修改服務器的最大連接數來解決問題。

　　（四）在Web Page Diagnostics（網頁分析）中

　　當在場景中打開Diagnostics菜單下的Web Page Diagnostics功能，就能得到網頁分析組圖。通過這個圖，可以對事務的組成進行抽絲剝繭的分析，得到組成這個頁面的每一個請求時間分析，進一步了解響應時間中有關網絡和服務器處理時間的分配關系。通過這個功能，可以實現對網站的前端性能分析，明確系統響應時間較長時由服務器端（后端）處理能力不足還是短連接到服務器的網絡（前端）消耗導致的。

　　1、 Web Page Diagnostics（網頁分析）

　　說明——添加該圖先會得到整個場景運行后虛擬用戶訪問的Page列表，也就是所有頁面下載時間列表。描述（在注冊用戶事務進行分析，整個負載由三個頁面請求組成，其中有一個請求始終在多少秒以內，而另外幾個請求時間較長并且有上升趨勢，然后通過Select Page to Break Down命令選擇具體的Page來獲得每個請求的相關詳細信息——分析如下：

　　1.Download Time下載時間分析——組成頁面的每個請求下載時間——可以看到創建用戶的操作由4個請求組成，其中導致注冊用戶較慢的主要原因是注冊完成后需要等待兩秒鐘再刷新至論壇首頁，而非注冊用戶本身需要消耗的時間，首頁刷新慢也只是因為Client（客戶端）需要消耗較多時間，同時Receive（接收）的時間也有一定的影響。

　　2.Component（Over time）各模塊的時間變化——通過這個功能可以分析響應時間變長是因為頁面生成慢，還是因為圖片資源下載慢。隨著時間的增加，首頁的處理時間（最上面的一根線）從多少秒上升到了最大值多少秒，而注冊英護響應時間幾乎沒有上升。

　　3.Download Time（Over time）模塊下載時間——針對每個組成頁面元素的時間組成部分分析，方便確認該元素的處理時間組成部分。發現首頁請求的下載時間主要消耗在Client上，而多少分多少秒之前Recevie所消耗的時間在逐漸變長。

　　4.Time to Buffer（Over time）模塊時間分類——列出該元素所使用的時間分配比例，是受Network Time影響的多還是Server Time影響的多。對于首頁刷新的響應時間來說，主要是Network Time網絡上消耗的時間，而Server Time服務器端的處理時非常優秀的。Server Time是服務器對該頁面的處理時間；Network Time是指網絡上的時間開銷。）

　　2、 Page Download Time Breakdown（頁面響應時間組成分析）

　　說明——顯示每個頁面響應時間的組成分析，一個頁面的響應時間一般由以下內容組成：

　　Client Time客戶端瀏覽接收所需要使用的時間，可以不用考慮。

　　Connections Time連接服務器所需要的時間，越小越好。

　　DNS Resolution Time通過DNS服務器解析域名所需要的時間，解析受到DNS服務器的影響，越小越好。

　　Error Time服務器返回錯誤響應時間，這個時間反映了服務器處理錯誤的速度，一般是Web服務器直接返回的，包含了網絡時間和Web服務器返回錯誤的時間，該時間越小越好。

　　First Buffer Time連接到服務器，服務器返回第一個字節所需要的時間，反映了系統對于正常請求的處理時間開銷，包含網絡時間和服務器正常處理的時間，該時間越小越好。

　　FTP Authentication Time FTP認證時間，這是進行FTP登錄等操作所需要消耗的認證時間，越短越好。

　　Receive Time接受數據的時間，這個時間反映了帶寬的大小，帶寬越大，下載時間越短。

　　SSL Handshaking Time SSL加密握手的時間，而Analysis在這里會分析得到頁面請求的組成比例圖，便于分析頁面時間浪費在哪些過程中。

　　3、 Page Download Time Breakdown（Over time）（頁面組成部分時間）

　　說明——隨著時間的變化所有請求的響應時間變化過程。這里會將整個負載過程中每個頁面的每個時間組成部分都做成單獨的時間線，以便分析再不同的時間點上組成該頁面的各個請求時間是如何變化的。描述（看到大多數頁面的響應時間是比較穩定的，其中首頁刷新變動較大——首先找到變化最明顯或者響應時間最高的頁面，隨后在針對這個頁面進行進一步的分析了解時間偏長或者變化較快的原因。）

　　4、 Time to First Buffer Breakdown（頁面請求組成時間）

　　說明——組成頁面時間請求的比例說明（客戶端時間/服務器時間），通過這個圖，我們可以直接地了解到整個頁面的處理是在服務器端消耗的時間長，還是在客戶端消耗的時間長，從而分析得到系統的性能問題是在前段還是在后端。描述（網絡或客戶端的時間開銷占了絕大多數）

　　5、 Time to First Buffer Breakdown（Over time）（基于時間的頁面請求組成分析）

　　說明——在整個負載過程中，每一個請求的Server Time和Client Time隨著時間變化的趨勢，可以方便定位響應時間隨著時間變化的原因到底是由于客戶端變化導致的還是由于服務器端變化導致的。描述（對于用戶注冊操作，望樓上的時間變化比服務器上的時間變化要劇烈）

　　（五）在Network Monitor（網絡監控）中

　　在 Controller中添加了Network Delay Time監控后會出現該數據圖。這個功能很好但并不是非常直觀和方便，建議使用第三方專門的路由分析工具進行網絡延遲和路徑分析。

　　1、Network Delay Time（網絡延遲時間）

　　說明——從監控機至目標主機的平均網絡延遲變化情況。描述（看到網絡延遲從多少毫秒逐漸減少到多少毫秒，最后上升到多少毫秒）。

　　2、Network Sub-Path Time（網絡Sub-Path時間）

　　說明——當客戶端在連接一個遠程服務器時，路徑并不是唯一的，收到路由器的路由選擇，可能會選擇不同的路徑最終訪問到服務器。描述（從監控服務區至目標服務器所經歷的路徑，以及每個路徑上的網絡延遲）

　　3、Network Segment Delay Time(網段延遲時間)

　　說明——各個路徑上的各個節點網絡延遲情況。描述（路由器和路由器之間的網絡延遲變化情況，以便于分析影響整個網絡時間的原因及節點）。

　　（六）在Resources（資源監控）中

　　資源包括很多種，在Analysis中監控的都市各種系統的計數器，這些計數器反映了系統中硬件或者軟件的運行情況，通過它可以發現系統的瓶頸。

　　1、 System Resources（系統資源）列出了再負載過程中系統的各種資源數據是如何變化的，該圖需要在場景中設置了對應系統的監控后才出現：

　　1.Database Server Resources（數據庫資源）

　　說明——數據庫的相關資源在負載過程中的變化情況。

　　2.Web Server Resources（Web服務器資源）

　　說明——Web服務器資源在負載過程中的變化情況。

　　（七）在Error（錯誤統計）中

　　當場景在運行中出現錯誤時，錯誤信息將會被保存在該計數器組中，通過Error信息可以了解錯誤產生的時間和錯誤的類型，幫助我們定位產生錯誤的原因。

　　Error per Second（每秒錯誤數）

　　說明——每秒錯誤數可以了解在每個時間點上錯誤產生的數目，該數據越小越好。通過這個圖可以了解錯誤隨負載的變化情況，定位何時系統在負載下開始不穩定甚至出錯，配合系統日志可以定位產生錯誤的原因。描述(看到場景在多少的時候出現了一次錯誤)。

　　Service Level Agreement Legend（SLA圖標說明）

　　1、圖標為灰色帶減號的為No Data，說明在SLA中未對這個數據項進行監控，沒有數據；

　　2、圖標為紅色帶叉的為Fail，說明在SLA中定義了該項的數據監控，但該數據未能達到期望的閥值；

　　3、圖標為綠色帶鉤的為Pass，說明在SLA中定義了該項的數據監控，該數據達到了期望閥值。

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Vusers (虛擬用狀態)

　　Vusers　用戶狀態計數器組提供了產生負載的虛擬用戶運行狀態的相關信息，可以幫助了解負載生成的過程。

　　Running Vusers(負載過程中的虛擬用戶運行情況)

　　此圖反映系統形成負載的過程，隨著時間的推移，虛擬用戶數是如何變化的。

　　Rendezvous(負載過程中集合點下的虛擬用戶)

　　當場景中設置了集合點后會出現該圖，反映了隨著時間的推移各個時間點上并發用戶的數目，方便了解并發用戶數的變化情況。

　　Errors(錯誤統計)

　　當場景在運行中出現錯誤時，錯誤信息將會保存在該計數器組中，通過 Error 信息可以了解錯誤產生的時間和錯誤的類型，幫助定位產生錯誤的原因。

　　Errors per Second(每秒錯誤數)

　　可以了解在每個時間點上錯誤產生的數目，該數據越小越好，通過該圖可以了解錯誤隨負載的變化情況，定位何時系統在負載下開始不穩定甚至出錯，配合系統日志可以定位產生錯誤的原因。

　　Transactions(事務)

　　給出所有和事務相關的數據統計，方便了解被測系統業務處理的響應時間和吞吐量。

　　事務默認狀態：PASS、FAIL、STOP，如果是手工事務那么狀態會有 PASS 和 FAIL 兩種。

　　Average Transaction Response Time(平均事務響應時間)

　　反映了隨著時間的變化事務響應時間的變化情況，時間越小說明處理的速度越快。

　　結合負載生成圖合并一起看，可以發現用戶負載增加對系統事務響應時間的影響規律。

　　Transactions per Second(每秒事務數)

　　另一個關鍵數據是 TPS 吞吐量，該數據反映了系統在同一時間內能處理業務的最大能力，這個數據越高，說明系統處理能力越強。

　　TPS 會受到負載的影響，也會隨著負載的增加而逐漸增加，當系統進入繁忙期后，TPS 會有所下降。

　　Transaction Summary(事務概要說明)

　　說明事務的 Pass 個數和 Fail 個數，了解負載的事務完成情況。通過的事務越多，說明系統的處理能力越強，失敗的事務越少，說明系統越可靠。

　　結合每秒錯誤數圖進一步分析錯誤產生的原因。

　　Transaction Performance Summary(事務性能概要)

　　事務的平均時間、最大時間、最小時間柱狀圖，方便分析事務響應時間的情況。

　　柱狀圖的落差越小說明系統響應時間的波動較小，如果落差很大，說明系統不夠穩定。

　　Transaction Response Time Under Load(在用戶負載下事務響應時間)

　　在負載用戶增長的過程中響應時間的變化情況，改圖的線條越平穩，說明系統越穩定。

　　Transaction Response Time(Percentile)(事務響應時間的百分比)

　　不同百分比下的事務響應時間范圍，可以了解有多少比例的事務發送在某個時間內，也可以發現響應時間的分布規律，數據越平穩說明響應時間變化越小。

　　Transaction Response Time(Distribution)(每個時間段上的事務數)

　　每個時間段上的事務個數，響應時間較小的分類下的事務數越多越好。

　　Web Resources(網頁資源信息)

　　給出的是對于 Web 操作的一些基本信息，這些信息在服務器端也能獲得，當 Controller 的 RunTime Setting 中 Preferences 下的 Generated Web performance graphs 選相處于開啟狀態時，才會得到該圖。

　　Hits per Second(每秒點擊數)

　　每秒點擊數提供了當前負載中對系統所產生的點擊量記錄。每一次點擊相當于對服務器發出了一次請求，一般點擊數會隨著負載的增加而增加，該數據越大越好。

　　Throughput(寬帶使用)

　　在當前系統下所使用的帶寬，該數據越小說明系統的帶寬依賴越小，通過這個數據能確定是否出現了網絡帶寬的瓶頸(注意使用單位為字節)。

　　HTTP Responses per Second(每秒 HTTP 響應數)

　　每秒鐘服務器返回各種狀態的數目，該數值一般和每秒點擊量相同。點擊量是指客戶端發出的請求數，而 HTTP 響應數是指服務器返回的響應數。如果服務器返回的響應數小于客戶端發出的點擊數，那么說明服務器無法應答超出負載的連接請求。

　　結合每秒點擊數看，如吻合，則說明服務器能夠對每一個客戶端請求進行應答。

　　Connections Per Second(每秒連接數)

　　給出兩種不同狀態的連接數，即中斷的連接和新建的連接，方便了解當前每秒對服務器產生連接的數量。

　　同時的連接數越多，說明服務器的連接池越大，當連接數隨著負載上升而停止上升時，說明系統的連接池已滿，無法連接更多的用戶，通常服務器會返回504錯誤。

　　可以通過修改服務器的最大連接數來解決該問題。

　　Web Page Diagnostics(網頁分析)

　　當在場景中打開 Diagnostics 菜單下的 Web Page Diagnostics 功能，就能得到網頁分析組圖。

　　通過該圖，可以對事務的組成進行抽絲剝繭的分析，得到組成這個頁面的每一個請求時間的分析，進一步了解響應時間中有關網絡和服務器處理時間的分配關系。通過該功能，可以實現對網站前端的性能分析，明確系統響應時間較長是由服務器端處理能力不足還是客戶端連接到服務器的網絡消耗導致的。

　　Web Page Diagnostics(網頁分析)

　　添加改圖先會得到真個個場景運行后虛擬用戶訪問 Page 列表，也就是所有頁面下載時間列表。

　　通過 Select Page to Break Down 命令選擇具體的 Page 來獲得每個請求的相關詳細信息。

　　Diagnostics options 選項提供四大塊功能。

　　Download Time(下載時間分析)

　　可以得到組成頁面的每個請求下載時間。

　　Component(Over time)(各模塊的時間變化)

　　列出組成頁面的每個元素，以及隨著時間的變化所帶來的響應時間變化。

　　通過該功能可以分析響應時間變長是因為頁面生成慢，還是因為圖片資源下載慢。

　　Download Time(Over time)(模塊下載時間)

　　提供了針對每個組成頁面元素的時間組成部分分析，方便確認該元素的處理時間組成部分。

　　Time to First Buffer(Over time)(模塊時間分類)

　　這里會列出該元素所使用的時間分配比例，是受 Network Time 影響的多還是 Server Time 影響的多。

　　Network Time：指網絡上的時間開銷。

　　Server Time：服務器對該頁面的處理時間。

　　Page Download Time Breakdown(頁面響應時間組成分析)

　　這張圖顯示了每個頁面響應時間的組成分析，一個頁面的響應時間一般由以下內容組成：

　　Client Time

　　客戶端瀏覽器接收所需要使用的時間，可以不考慮。

　　Connections Time

　　連接服務器所需要時間，越小越好。

　　DNS Resolution Time

　　通過 DNS 服務器解析域名所需要的時間，解析受到 DNS 服務器的影響，越小越好。

　　Error Time

　　服務器返回錯誤響應時間，這個時間反映了服務器處理錯誤的速度，一般是 Web 服務器直接返回的，包含了網絡時間和 Web 服務器返回錯誤的時間，該時間越小越好。

　　First Buffer Time

　　連接到服務器，服務器返回第一個字節所需要的時間，反映了系統對于正常請求的處理時間開銷，包含了網絡時間和服務器正常處理的時間，該時間越小越好。

　　FTP Authentication Time

　　FTP 認證時間，這是進行 FTP 登錄等操作所需要消耗的認證時間，越短越好。

　　Receive Time

　　接受數據的時間，這個時間反映了帶寬的大小，帶寬越大，下載時間越短。

　　SSL Handshaking Time

　　SSL加密握手時間

　　得到頁面請求的組成比例圖，便于分析頁面時間浪費在那些過程中。

　　Page Download Time Breakdown(Over Time)(頁面組成部分時間)

　　提供了隨著時間的變化所有請求的響應時間變化過程。將整個負載過程中每個頁面的每個時間組成部分都做成單獨的時間線，以便分析在不同的時間點上組成該頁面的各個請求時間是如何變化的。

　　首先找到變化最明顯或者響應時間最高的頁面，隨后再針對這個頁面進行進一步的分析了解時間偏長或者變化快的原因。

　　Time to First Buffer Breakdown(頁面請求組成時間)

　　提供了組成頁面時間請求的比列說明(客戶端時間/服務器時間)，通過這個圖，可以直觀的了解到整個頁面的處理是在服務器端消耗的時間長，還是在客戶端消耗的時間長。從而分析得到系統的性能問題是在前端還是后端。

　　Time to First Buffer Breakdown(Over Time)(基于時間的頁面請求組成分析)

　　給出了整個負載過程中，每一個請求的 Server Time 和 Client Time 隨著時間變化的趨勢，可以方便定位響應時間隨著時間變化的原因到底是由于客戶端變化導致的還是由于服務器端變化導致的。