一、用戶事務分析

用戶事務分析是站在用戶角度進行的基礎性能分析。

1.Transation Sunmmary（事務綜述）

對事務進行綜合分析是性能分析的第一步，通過分析測試時間內用戶事務的成功與失敗情況，可以直接判斷出系統是否運行正常。

2.Average Transaciton Response Time（事務平均響應時間）

“事務平均響應時間”顯示的是測試場景運行期間的每一秒內事務執行所用的平均時間，通過它可以分析測試場景運行期間應用系統的性能走向。根據該圖，可以定位出現性能問題的轉折點。

說明：隨著測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨著投產時間的變化，整體性能將會有下降的趨勢。

當事務響應時間的曲線開始由緩慢上升，然后處于平衡，最后慢慢下降，可能情況：

1. 曲線圖持續上升，表明系統的處理能力在下降，事務的響應時間變長
2. 持續平衡，表明并發用戶數達到一定數量，再多請求也可能接受不了，等待
3. 當事務的響應時間在下降，表明并發用戶的數量在慢慢減少，事務的請求數也在減少。

如果系統沒有出現下降，但響應時間越來越長，直到系統癱瘓，引起原因可能如下:

1. 程序中用戶數連接未做限制，導致請求數不斷上升，響應時間不斷變長
2. 內存泄露

3.Transactions per Second（每秒通過事務數，簡寫TPS）

“每秒通過事務數/TPS”顯示在場景運行的每一秒鐘，每個事務通過、失敗以及停止的數量，使考查系統性能的一個重要參數。通過它可以確定系統在任何給定時刻的時間事務負載。分析TPS主要是看曲線的性能走向。將它與平均事務響應時間進行對比，可以分析事務數目對執行時間的影響。

說明：當壓力加大時，點擊率/TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是服務器開始出現瓶頸。TPS值，越大說明系統處理能力越強。

4.Total Transactions per Second（每秒通過事務總數）

“每秒通過事務總數”顯示在場景運行時，在每一秒內通過的事務總數、失敗的事務總署以及停止的事務總數。該曲線走向和TPS曲線走向一致。

5.Transaction Performance Sunmmary（事務性能摘要）

“事務性能摘要”顯示方案中所有事務的最小、最大和平均執行時間，可以直接判斷響應時間是否符合用戶的要求。

說明：重點關注事務的平均和最大執行時間，如果其范圍不在用戶可以接受的時間范圍內，需要進行原因分析。

6.Transaction Response Time Under Load（事務響應時間與負載）

“事務響應時間與負載”是“正在運行的虛擬用戶”圖和“平均響應事務時間”圖的組合，通過它可以看出在任一時間點事務響應時間與用戶數目的關系，從而掌握系統在用戶并發方面的性能數據，為擴展用戶系統提供參考。此圖可以查看虛擬用戶負載對執行時間的總體影響，對分析具有漸變負載的測試場景比較有用。

7.Transaction Response Time(Percentile)（事務響應時間(百分比)）

“事務響應時間(百分比)”是根據測試結果進行分析而得到的綜合分析圖，也就是工具通過一些統計分析方法間接得到的圖表。通過它可以分析在給定事務響應時間范圍內能執行的事務百分比。

說明：主要觀察，在給定時間的范圍內完成事務的百分比 參考值： 10%的TRT（P）<=5s、50%的TRT（P）<=5s、90%的TRT（P）<=5s

8.Transaction Response Time(Distribution)（事務響應時間(分布)）

“事務響應時間(分布)”顯示在場景運行過程中，事務執行所用時間的分布，通過它可以了解測試過程中不同響應時間的事務數量。如果系統預先定義了相關事務可以接受的最小和最 大事務響應時間，則可以使用此圖確定服務器性能是否在可以接受的范圍內。

說明：主要觀察，大多數事務的響應時間。 參考值：TRT（D）<=5s

二、確定CPU、內存泄露問題

1.%processor time(processor_total)

服務器消耗的處理器時間數量.如果服務器專用于sql server 可接受的最大上限是80% -85 %.也就是常見的CPU使用率。

說明：正常負載下，服務器的CPU利用率應該在80%以下。超過90%,那么很可能存在處理器瓶頸。如果CPU使用率不斷上升，內存使用率也不斷上升，表明系統可能產生資源爭用情況，引起原因，程序資源調配問題。

判斷是否內存泄露問題：

內存問題主要檢查應用程序是否存在內存泄漏,如果發生了內存泄漏，P rocess Bytes\Private Bytes計數器和Process\Working set 計數器的值往往會升高，同時Avaiable bytes的值會降低。內存泄漏應該通過一個長時間的，用來研究分析所有內存都耗盡時，應用程序反應情況的測試來檢驗。內存泄露問題經常出現在服務長時間運轉的時候,由于部分程序對內存沒有釋放，而將內存慢慢耗盡，也是提醒大家對系統穩定性測試的關注。

2.%Disk time(physicaldisk_total)

指所選磁盤驅動器忙于為讀或寫入請求提供服務所用的時間的百分比。如果三個計數器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數器之前，請在Windows 2000 的命令行窗口中運行diskperf -yD。

說明：正常值< 10。若數值持續超過80%，則可能是內存泄漏。

3.Availiable bytes(memory)

用物理內存數. 如果Available Mbytes的值很小(4 MB 或更小)，則說明計算機上總的內存可能不足，或某程序沒有釋放內存。

參考值：4 MB或更小，至少要有10%的物理內存值。

4.Page write/sec

(寫的頁/秒)每秒執行的物理數據庫寫的頁數。

說明：如果服務器沒有足夠的內存處理其工作負荷，此數值將一直很高。如果大于80，表示有問題(太多的讀寫數據操作要訪問磁盤，可考慮增加內存或優化讀寫數據的算法)。

【其他參數】

%User time(processor_total)

表示耗費CPU的數據庫操作，如排序，執行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯接，水平分割大表格等方法來降低該值。

%DPC time(processor_total)

越低越好。在多處理器系統中，如果這個值大于50%并且Processor:% Processor Time非常高，加入一個網卡可能會提高性能，提供的網絡已經不飽和。

Context switch/sec(system)

(實例化inetinfo 和dllhost 進程) 如果你決定要增加線程字節池的大小，你應該監視這三個計數器(包括上面的一個)。增加線程數可能會增加上下文切換次數，這樣性能不會上升反而會下降。如果十個實例的上下文切換值非常高，就應該減小線程字節池的大小。

說明：可判斷應用程序的問題。如果系統由于應用程序代碼效率低下或者系統結構設計有缺陷而導致大量的上下文切換(Context switches/sec顯示的上下文切換次數太高)那么就會占用大量的系統資源,如果系統的吞吐量降低并且CPU的使用率很高,并且此現象發生時切換水平在15000以上,那么意味著上下文切換次數過高。

%Disk reads/sec(physicaldisk_total)

每秒讀硬盤字節數。

%Disk write/sec(physicaldisk_total)

每秒寫硬盤字節數。

Page faults/sec

進程產生的頁故障與系統產生的相比較，以判斷這個進程對系統頁故障產生的影響。

Pages per second

每秒鐘檢索的頁數。

該數字應少于每秒一頁Working set:理線程最近使用的內存頁，反映了每一個進程使用的內存頁的數量。如果服務器有足夠的空閑內存，頁就會被留在工作集中，當自由內存少于一個特定的閾值時，頁就會被清除出工作集。

Avg.disk queue length

讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。該值應不超過磁盤數的1.5~2 倍。要提高性能，可增加磁盤。注意：一個Raid Disk實際有多個磁盤。

Average disk read/write queue length

指讀取(寫入)請求(列隊)的平均數Disk reads/(writes)/s:理磁盤上每秒鐘磁盤讀、寫的次數。兩者相加，應小于磁盤設備最大容量。

Average disk sec/read

以秒計算的在此盤上讀取數據的所需平均時間。Average disk sec/transfer:指以秒計算的在此盤上寫入數據的所需平均時間。

Bytes total/sec

為發送和接收字節的速率，包括幀字符在內。判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較Page read/sec:每秒發出的物理數據庫頁讀取數。這一統計信息顯示的是在所有數據庫間的物理頁讀取總數。由于物理 I/O 的開銷大，可以通過使用更大的數據高速緩存、智能索引、更高效的查詢或者改變數據庫設計等方法，使開銷減到最小。

三、確定網絡問題

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

“每秒點擊次數”，即使運行場景過程中虛擬用戶每秒向Web服務器提交的HTTP請求數。 通過它可以評估虛擬用戶產生的負載量，如將其和“平均事務響應時間”圖比較，可以查看點擊次數對事務性能產生的影響。

說明：通過對查看“每秒點擊次數”，可以判斷系統是否穩定。系統點擊率下降通常表明服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。

2.Throughput（吞吐率）

“吞吐率”顯示的是場景運行過程中服務器的每秒的吞吐量。其度量單位是字節，表示虛擬用在任何給定的每一秒從服務器獲得的數據量。可以依據服務器的吞吐量來評估虛擬用戶產生的負載量，以及看出服務器在流量方面的處理能力以及是否存在瓶頸。 “吞吐率”圖，是每秒服務器處理的HTTP申請數。 “點擊率”圖，是客戶端每秒從服務器獲得的總數據量。

說明：觀察3張圖（Running Vusers（負載數）/His per Second（點擊率）/Throughput(吞吐量)），隨著負載的加大，點擊率和吞吐量會隨之增大。如果系統的吞吐量隨著負載的加大出現平坦或降低并且CPU的使用率很高,并且此現象發生時切換水平在15000以上,那么意味著上下文切換次數過高，表明網絡飽和。

3.Network Delay Time

說明：網絡延遲時間的曲線突起顯示有網絡故障。

4.Network Sub-Path Time

說明：網絡Sub-Path的時間曲線跳躍式的突起證明存在網絡故障。

四、確定性能問題是在網絡端還是服務端

1.Web Page Breakdown（頁面分解總圖）

“頁面分解”顯示某一具體事務在測試過程的響應情況，進而分析相關的事務運行是否正常。可以按下面四種方式進行進一步細分：

Download Time Breaddown（下載時間細分）

“下載時間細分”圖顯示網頁中不同元素的下載時間，同時還可按照下載過程把時間進行分解，用不同的顏色來顯示DNS解析時間、建立連接時間、第一次緩沖時間等各自所占比例。

Component Breakdown(Over Time)（組件細分(隨時間變化)）

“組件細分”圖顯示選定網頁的頁面組件隨時間變化的細分圖。通過該圖可以很容易的看出哪些元素在測試過程中下載時間不穩定。該圖特別適用于需要在客戶端下載控件較多的頁面，通過分析控件的響應時間，很容易就能發現那些控件不穩定或者比較耗時。

Download Time Breakdown(Over Time)（下載時間細分(隨時間變化)）

“下載時間細分(隨時間變化)” 圖顯示選定網頁的頁面元素下載時間細分（隨時間變化）情況，它非常清晰地顯示了頁面各個元素在壓力測試過程中的下載情況。

“下載時間細分”圖顯示的是整個測試過程頁面元素響應的時間統計分析結果，“下載時間細分(隨時間變化)”顯示的事場景運行過程中每一秒內頁面元素響應時間的統計結果，兩者分別從宏觀和微觀角度來分析頁面元素的下載時間。

Time to First Buffer Breakdown(Over Time)（第一次緩沖時間細分(隨時間變化)）

“第一次緩沖時間細分(隨時間變化)&rdquo;圖顯示成功收到從Web服務器返回的第一次緩沖之前的這段時間，場景或會話步驟運行的每一秒中每個網頁組件的服務器時間和網絡時間（以秒為單位）。可以使用該圖確定場景或會話步驟運行期間服務器或網絡出現問題的時間。

First Buffer Time：是指客戶端與服務器端建立連接后，從服務器發送第一個數據包開始計時，數據經過網絡傳送到客戶端，到瀏覽器接收到第一個緩沖所用的時間。

2.Page Component Breakdown（頁面組件細分）

“頁面組件細分”圖顯示每個網頁及其組件的平均下載時間（以秒為單位）。可以根據下載組件所用的平均秒數對圖列進行排序，通過它有助于隔離有問題的組件。

3.Page Component Breakdown(Over Time)（頁面組件分解(隨時間變化)）

“頁面組件分解(隨時間變化)”圖顯示在方案運行期間的每一秒內每個網頁及其組件的平均響應時間 （以秒為單位）。

4.Page Download Time Breakdown（頁面下載時間細分）

“頁面下載時間細分”圖顯示每個頁面組件下載時間的細分，可以根據它確定在網頁下載期間事務響應時間緩慢是由網絡錯誤引起還是由服務器錯誤引起。

“頁面下載時間細分”圖根據DNS解析時間、連接時間、第一次緩沖時間、SSL握手時間、接收時間、FTP驗證時間、客戶端時間和錯誤時間來對每個組件的下載過程進行細分。

5.Page Download Time Breakdown(Over Time)（頁面下載時間細分(隨時間變化)）

“頁面下載時間細分(隨時間變化)”圖顯示方案運行期間，每一秒內每個頁面組件下載時間的細分。使用此圖可以確定網絡或服務器在方案執行期間哪一時間點發生了問題。 “頁面組件細分(隨時間變化)”圖和“頁面下載時間細分(隨時間變化)”圖通常結合起來進行分析：首先確定有問題的組件，然后分析它們的下載過程，進而定位原因在哪里。

6.Time to First Buffer Breakdown（第一次緩沖時間細分）

“第一次緩沖時間細分”圖顯示成功收到從Web服務器返回的第一次緩沖之前的這一段時間內的每個頁面組件的相關服務器/網路時間。如果組件的下載時間很長，則可以使用此圖確定產生的問題與服務器有關還是與網絡有關。

網絡時間：定義為第一個HTTP請求那一刻開始，直到確認為止所經過的平均時間。 服務器時間：定義為從收到初始HTTP請求確認開始，直到成功收到來自Web服務器的一次緩沖為止所經過的平均時間。

說明：找出下載耗費時間最多的網頁。有助排出DNS的故障，SSL的故障，網絡連接的故障。 【其他Web資源分析】

1.HTTP Status Code Summary（HTTP狀態代碼概要）

“HTTP狀態代碼概要”顯示場景或會話步驟過程中從Web服務器返回的HTTP狀態代碼數，該圖按照代碼分組。HTTP狀態代碼表示HTTP請求的狀態。

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

“每秒HTTP響應數”是顯示運行場景過程中每秒從Web服務器返回的不同HTTP狀態代碼的數量，還能返回其它各類狀態碼的信息，通過分析狀態碼，可以判斷服務器在壓力下的運行情況，也可以通過對圖中顯示的結果進行分組，進而定位生成錯誤的代碼腳本。

3.Pages Downloader per Second（每秒下載頁面數）

“每秒下載頁面數”顯示場景或會話步驟運行的每一秒內從服務器下載的網頁數。使用此圖可依據下載的頁數來計算Vuser生成的負載量。

和吞吐量圖一樣，每秒下載頁面數圖標是Vuser在給定的任一秒內從服務器接收到的數據量。但是吞吐量考慮的各個資源極其大小（例，每個GIF文件的大小、每個網頁的大小）。而每秒下載頁面數只考慮頁面數。

注：要查看每秒下載頁數圖，必須在R-T-S那里設置“每秒頁面數(僅HTML模式)”。

4.Retries per Second（每秒重試次數）

“每秒重試次數”顯示場景或會話步驟運行的每一秒內服務器嘗試的連接次數。 在下列情況將重試服務器連接： A、初始連接未經授權 B、要求代理服務器身份驗證 C、服務器關閉了初始連接 D、初始連接無法連接到服務器 E、服務器最初無法解析負載生成器的IP地址

5.Retries Summary（重試次數概要）

“重試次數概要”顯示場景或會話步驟運行過程中服務器嘗試的連接次數，它按照重試原因分組。將此圖與每秒重試次數圖一起使用可以確定場景或會話步驟運行過程中服務器在哪個時間點進行了重試。

6.Connections（連接數）

“連接數”顯示場景或會話步驟運行過程中每個時間點打開的TCP/IP連接數。 借助此圖，可以知道何時需要添加其他連接。

說明：當連接數到達穩定狀態而事務響應時間迅速增大時，添加連接可以使性能得到極大提高（事務響應時間將降低）。

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

“每秒連接數”顯示方案在運行過程中每秒建立的TCP/IP連接數。 理想情況下，很多HTTP請求都應該使用同一連接，而不是每個請求都新打開一個連接。通過每秒連接數圖可以看出服務器的處理情況，就表明服務器的性能在逐漸下降。

8.SSLs Per Second（每秒SSL連接數）

“每秒SSL連接數”顯示場景或會話步驟運行的每一秒內打開的新的以及重新使用的SSL連接數。當對安全服務器打開TCP/IP連接后，瀏覽器將打開SSL連接。

9.Web Page Breakdown（網頁元素細分）

“網頁元素細分”主要用來評估頁面內容是否影響事務的響應時間，通過它可以深入地分析網站上那些下載很慢的圖形或中斷的連接等有問題的 元素。

10.Time to First Buffer Breakdown(Over Time)（第一次緩沖時間細分(隨時間變化)）

&ldquo;第一次緩沖時間細分(隨時間變化)”圖顯示成功收到從Web服務器返回的第一個緩沖之前的這段時間內，場景運行的每一秒中每個網頁組件的服務器時間和網絡時間。可以使用此圖確定場景運行期間服務器或網絡出現問題的時間點。

11.Downloader Component Size(KB)（已下載組件大小）

“已下載組件大小”圖顯示每個已經下載的網頁組建的大小。通過它可以直接看出哪些組件比較大并需要進一步進行優化以提高性能。