一、何時需要進行性能測試分析？
- 如果性能測試結束後，所以的結果數據均正常或者符合需求指標，則不需要分析
- 如果測試結果有問題，則需要分析
二、性能測試分析的情況及過程
- 如果測試結果沒有問題，則不需要分析
- 如果測試結果中存在較小的問題，則需要從analysis中查看問題原因，一般容易解決。這需要對結果報告有所瞭解。
- 如果上步無法解決的問題，則分析的過程比較複雜。
①如果一個測試結束後，發現某事務響應時間過長（13s），該如何解決（該問題假如通過上步沒有解決）？
②首先通過Analysis中的頁面診斷圖（網頁細分圖）去查找響應時間長到哪裏。響應時間=客戶端時間+網絡時間+服務器時間。該種情況下，絕大部分都是服務器的瓶頸。
③通過監控被測系統中所有服務器的性能資源，即服務器資源圖。通過改圖，可以輕鬆的判斷出哪臺服務器不正常。
④服務器一般分爲應用服務器（也叫中間件）【比如Tomcat】、數據庫服務器。
⑤如果應用服務器有問題，修改一些參數即可。
⑥大部分的情況都是數據庫服務器有問題，這種情況一般需要部署專門的服務器監控工具（如oracle的監控工具quest、lab128）去監控，可以很輕鬆的找到底層的數據庫問題，如索引、甚至SQL語句的問題，進而進行調優，提升被測系統的性能。
Graphs—>Add New Item—>Add New Graph—>Web Page Diagnostics中的七張圖
三、頁面組件細分圖
①Page Component Breakdown（頁面組件細分圖）
顯示每個頁面及其組件的平均響應時間，查看所選擇頁面中哪個元素所佔的平均響應時間最長。
包含事務和頁面：
對事務舉個栗子：當點擊訂票後，會新出現一個頁面，將頁面中所有元素下載完畢的時間
頁面：非事務的頁面下載各元素的時間
點擊：127.0…ebTours/login.pl(main URL)是加載完這個頁面的時間，將餅狀圖劃分爲多塊，每部分是佔總時間的比例。
②Page Component Breakdown(over Time)頁面組件細分（隨時間變化）
- 整個測試過程中，任意一秒內頁面中每個元素的響應時間
如在runtime中設置了browser cache，則頁面中的資源文件只在第一次下載，後面的頁面響應時間包括這些元素的時間，這在Page Component Breakdown中顯示不出來，通過over time圖可以看出來
（非時間變化圖注重的是宏觀的表現；隨時間變化圖注重的是元素在測試過程中圍觀細節表現）一般測試中查看的順序：先宏觀後微觀
從圖中可以看出，頁面元素都被cache了，說明場景啓動了browser cache，頁面的響應時間只包含紅線和藍線。
四、頁面下載時間細分
①Page Download Time Breakdown（頁面下載時間細分）
DNS Resolution
- DNS—Domain name system—域名系統（出現原因：爲了便於記憶，將服務器的ip地址形成爲域名，一般具有一定意義）
- 在局域網內直接使用IP訪問，則不存在該時間
Connection
- 解析出Web Server 的IP地址後，瀏覽器請求發送到Web Server ，然後瀏覽器和Web Server之間需要建立一個初始化HTTP連接，服務器端需要做兩件事：一是接收請求，二是分配進程，建立該鏈接的過程就是connection時間。
First Buffer
- First buffer :第一個數據包時間，即網絡時間+服務器時間
- 顯示從初始HTTP請求到成功收到來自Web服務器的第一個數據包爲止所經過的時間
- 第一次緩衝度量是很好的Web服務器延遲和網絡滯後指示器
- 注意：由於緩衝區大小最大爲8k，因此第一次緩衝時間可能也就是完成元素下載所需的時間
Receive
- 從瀏覽器接收到第一個字節起，直到成功收到最後一個字節所經歷的時間，可以和組件大小結合，判斷網絡質量。也和客戶端和服務器有關係：和客戶端的關係：如果服務器發送過來大量的數據包，但是客戶端接收有問題，甚至無法全部接收。和服務器也有關係：服務器發送慢
SSL Handshaking
- 顯示建立SSL連接所用的時間。此時刻後，客戶端和服務器之間的所有通信都被加密。
- SSL握手度量僅適用於HTTPS通信
Client Time
- 請求在客戶端瀏覽器延遲的時間，可能是由於客戶端瀏覽器的處理時間或者客戶端其他方面引起的延遲。
Error Time
- 從發送HTTP請求，到Web Server 返回一個HTTP錯誤信息需要的時間
FTP
- 僅限FTP服務器測試
每個頁面中的元素下載，各部分所佔時間。在這種圖中connection time和first buffer都是佔時間較多，所以體現的較明顯，而其餘部分佔的少，也有在這張圖中。可以隱藏first buffer則其他部分時間顯示的就明顯了。
②Page Download Time Breakdown（Over Time）（頁面下載時間細分（隨時間變化））
在整個測試過程中，任意一秒內頁面中每個元素的響應時間分割圖
右面線條數目：以login爲例，元素數X8
發現佔時間比例最大的是first buffer時間
五、Time to First Buffer Breakdown（第一次緩衝細分時間）
①Time to First Buffer Breakdown
- 網絡時間：從發送第一個HTTP請求那一刻直到收到確認（確認：服務器確認收到）爲止，所經歷的平均時間
- 服務器時間：從收到初始HTTP請求確認直到成功收到來自Web服務器的第一次緩衝爲止，所經歷的平均時間。（所以，這部分雖然名稱叫服務器時間，但是從該定義來講，也存在網絡時間，又因爲一般在性能測試時，用內網有充足的帶寬，所以就剩服務器時間了）
發現佔該圖中時間比例最大的一般是服務器時間。
②Time to First Buffer Breakdown（over time）
buy中有兩項，所以右邊4條線。
六、已下載組件大小
①Downloaded Component Size(KB)
- 通過它可以直接看出哪些組件比較大並且需要進一步進行優化以提高性能。
網頁的大小是網頁中所有組件大小的和。
七、web page breakdown網頁細分圖
- Download time breakdown
- Component breakdown(overtime)
- Download time breakdown(overtime)
- Time to first buffer breakdown(overtime)
他們和七之前的breakdown不同的是：只要針對某個page的具體元素如圖片進行breakdown，因此前面沒有加page。
網頁細分綜合圖的打開方式：①在事務的平均響應時間圖中，查看響應時間最長的事務，點擊右鍵–打開該事務的網頁細分圖
②從graph中添加—打開網頁細分綜合圖
讀圖順序：從download time中可以看到佔該事務下載時間最長的，即瓶頸，若是first buffer，則再點開Time fo First Buffer(Over Time)從裏面找更細瓶頸。
一張圖片163k，相當於0.2M，當前1000用戶併發，則0.2M*1000=200M，網速一般10Mb（1B=8b）,200M/(10M/8)=150s左右。
Bmp—-基於無損壓縮，圖片中每個像素都是24bits，則1024*768*24bit=所以這種類型的圖片無論是一張白紙還是一張色彩斑斕的圖片，大小相似。
Jpg—基於有損壓縮，圖片中存儲像素之間的色彩差值，即如果一張白紙，會比彩色圖片存儲小的多。