3.業務操作響應時間：
使用“事務性能摘要”圖，可以確定在方案執行期間響應時間過長的事務。
顏色 比例 度量
1 最小值
1 平均值
1 最大值
分析事務的響應情況，要每次詳細分析，目前還只能觀察到響應時間過長的事務!
4.每秒點擊數
負載測試期間每秒內 Vuser 在 Web 服務器上點擊的次數�？筛鶕c擊次數來估算 Vuser 生成的負載數。
顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD
1 點擊次數 69.908 105.736 130.244 103.666 12.186
從圖中不難看出，在4小時的時候，點技數明顯增高。和apache的每秒點擊數增大的時間相吻合!
5.吞吐量
負載測試期間 Web 服務器上的吞吐量(字節)。吞吐量表示在任何指定秒內 Vuser 從服務器接收到的數據量。此圖可估計 Vuser 生成的負載量(服務器吞吐量)。
顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD
1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473
同樣，從圖中可以看出，在4個小時的時候，web服務器的吞吐量開始增高。在圖中還可以看到吞吐量的走勢圖，從開始到進行到4個小時反彈之前呈降低的趨勢，這是因為系統在初期調用的資源都是直接來之服務器，運行一段時間后系統的部分資源來自緩存。
6.下載組件大小
每個頁面的組件大小，且包括組件的標頭的大小!
頁面組件大小的分析表格比較復雜，實際分析中可以通過loadrunner的報告分析工具來分析。頁面組件大小分析主要是找到頁面中比較龐大的組件，如果其影響到了頁面的下載速度，則要想辦法將其改小!
7.Apache資源
顯示APACHE web服務器上的資源摘要。前面已經提到過以并發點擊數為主。
顏色 比例 度量 最小值 平均值 最大值 SD
100 Apache CPU 使用情況(Apache):172.17.7.210 0.777 0.852 0.93 0.043
0.01 已發送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924
0.1 點擊次數/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201
三.服務器資源監控指標
(目前通過top監察)
內存：
Linux資源監控中指標內存頁交換速率(Paging rate)，如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。
實際測試中，當并發點擊數出現突然劇增前后，內存的PR 值則居高25不下。說明目前測試的系統中內存存在瓶頸!
內存資源成為系統性能的瓶頸的征兆:
很高的換頁率(high pageout rate);
進程進入不活動狀態;
交換區所有磁盤的活動次數可高;
可高的全局系統CPU利用率;
內存不夠出錯(out of memory errors)
處理器：
Linux資源監控中指標CPU占用率持續超過80%(對該值的要求，根據具體應用和機器配置而要求不同，有資料表明95%)，表明瓶頸是CPU。
實際測試中，當并發點技數出現突然增加前后，cpu的占用率持續保持在86%以上!
說明，目前系統用應用的cpu也是測試的瓶頸!
CPU資源成為系統性能的瓶頸的征兆:
很慢的響應時間(slow response time)
CPU空閑時間為零(zero percent idle CPU)
過高的用戶占用CPU時間(high percent user CPU)
過高的系統占用CPU時間(high percent system CPU)
長時間的有很長的運行進程隊列(large run queue size sustained over time)
四.數據庫服務器
數據庫服務器目前測試觀察，當web服務器點擊率增大時，觀察mysql數據庫的最大連接數，仍未超過系統設置的最大連接數。所以，暫時未發現數據庫的瓶頸!
五.結論
以上報告分析中的數據、圖標均來自同一次測試。是在平時測試中挑出的一次現象比較明顯，比較利于觀察的作為分析案例。
根據以上綜合分析，當前測試環境下，當應用系統產生最大533.667的并發壓力。平均負載壓力114.352。根據分析，用戶在4個小時的時候，并發數迅速增加前后的值在400左右!分析結果跟實際測試的硬件環境以及測試腳本有一定關系。同時，測試服務器的硬件配置和實際服務器的配置還有一定的差距!
文章來源于領測軟件測試網 http://www.kjueaiud.com/
