一、
Web Page Breakdown
DNS
解析時間：
顯示使用最近的
DNS
服務器將
DNS
名稱解析為
IP
地址所需的時間；
DNS
查找度量是指示
DNS
解析問題或
DNS
服務器問題的一個很好的指示器；
Connect
時間：
顯示與包含指定
URL
的
Web
服務器建立初始連接所需的時間；
Connect
度量是一個很好的網絡問題指示器；它還可表明服務器是否對請求做出響應；
First buffer
時間：
顯示從初始
HTTP
請求到成功收回來自
WEB
服務器的第一次緩沖時為止所經過的時間；
First buffer
度量是很好的
Web
服務器延遲和網絡滯后指示器；
SSL Handshaking time
：
顯示建立
SSL
連接所用的時間
Receive Time
：
顯示從服務器收到最后一個字節并完成下載之前經過的時間；接收度量是很好的網絡質量指示器；
FTP
驗證時間：
顯示驗證客戶端所用的時間。
Client Time
：
顯示因瀏覽器思考時間或其他與客戶端有關的延遲而使客戶機上的請求發生延遲時，所經過的時間。
Error
時間：
顯示從發出
HTTP
請求到返回錯誤消息這期間所經過的平均時間
?
（
2007-1-11
）
?
二、
關于
TPS
（
Transactions per Second
）：
每秒處理事務數
?
這個值可以說明系統在特定的負載情況下，每秒可以處理多少個客戶端請求，這是一個衡量服務器端性能的重要指標，相信各位在進行性能測試的時候經常會用到這個指標。但是一直以來我都有一個疑問，到底這個值是怎么算出來的。既然是每秒事務數，那算法自然是“事務數
/
時間”。事務數很好理解，執行了多少就是多少，關鍵是這個時間。是整個場景執行的時間，還是僅僅是在服務器端執行的時間？因為我們知道，這兩個時間肯定是有區別的，前者還包括
thinktime
的時間、
pacing
的時間以及在網絡上耗費的時間等等。
為了弄明白這個問題，我今天特地查了一下幫助文檔，看到上面是這么說的：“每秒事務數圖顯示在場景或會話步驟運行的每一秒中，每個事務通過、失敗以及停止的次數。”如果按照這句話去理解，那么上面那個問題的答案應該是后者，也就是說，在
Transaactions per Second
這張圖中，
LoadRunner
是針對場景運行過程中的每一個時間點取樣一次，顯示在這個時間點上每個事務的通過、失敗以及停止的個數。
另外，我還在
Analysis
里面找了一下，發現圖表的時間顯示粒度也是可以設置的。具體方法為：在圖表上點擊右鍵
->
選擇“
Set
Granularity
”或者直接按
Ctrl+G
。我試著把時間粒度調成以毫秒為單位，結果
LoadRunner
提示當前不支持以毫秒為顯示粒度，由此我推斷
LoadRunner
對于
Transactions per Second
這張圖，最小的取樣粒度為
1
秒。
（
2007-2-8
）
?
三、
事務響應時間（百分比）圖
?
這個圖顯示的是事務響應時間范圍的分布情況。在場景的執行中，每個定義的事務可能會不止被處理一次（因為設置了持續時間或者迭代次數），
LoadRunner
會為每個事務實例的處理分別記錄響應時間。在
Summary Report
中，
LoadRunner
會針對每個事務的響應時間數據集合，分別取它的最大值、最小值和平均值，通常我們會關注響應時間的平均值。然而很多時候，單單是平均響應時間可能是不夠的，因為一旦最大值和最小值出現較大的偏差，即便平均響應時間處在可以接受的范圍內，但并不意味著整個系統的性能就是可以接受的，我們有必要再借助其它的分析報表來進一步分析，此時事務響應時間（百分比）圖就派上用場了。
事務響應時間（百分比）給出的是每個事務的響應時間按百分比的分布情況，它告訴我們本次測試有多少個事務的平均響應時間是落在我們可以接受的時間范圍之內。如果最大響應時間非常長，但是絕大多數事務（通常情況下以
95%
為參考）的響應時間具有可以接受的響應時間，則我們認為整個系統的性能還是可以接受的。
注意：
Analysis
將對每個可用事務百分比的事務響應時間取近似值。因此
Y
軸的值可能并不準確。
（
2007-2-8
）
?
四、
事務響應時間（負載下）圖
?
這個圖顯示的是事務響應時間隨著場景中虛擬用戶的逐漸增長的變化趨勢圖，該圖可以幫助我們查看
Vuser
負載對性能問題的影響。當我們需要了解某個事務的響應時間隨著虛擬用戶的增加而產生的變化時，可以通過在控制臺中設置一個漸變負載的場景的方式來實現。
例如每
5
分鐘加載
10
個用戶等，然后考察得到的這張圖表，就能夠對此有一個比較好的理解。
（
2007-2-14
）