根據業務的運行情況入手，以突出問題為主線，定位瓶頸，進行調優；執行后再驗證性能，未達到性能需求繼續找突出問題，分步調優。本分析以error為主線，找error的產生原因，定位到了瓶頸，針對瓶頸做調優。性能分析包含系統架構的各方面、各環節。
⑴.Analysis Summary
場景的大概情況。
現象：
Transaction Summary 部分顯示：
Average表明事務的平均響應時間。響應最慢的事務：check_itinerary；
Fail表示事務失敗的個數。失敗較多的事務：check_itinerary；
Std. Deviation表明事務的波動情況、穩定性。波動較大的事務：check_itinerary；
90 Percent表明90%的事務的響應時間，波動大的事務查看90%的響應時間較准確。90%響應時間較大的事務：check_itinerary；
分析：
從響應時間、波動性、失敗情況可以看出問題最突出是check_itinerary事務，進一步分析該事務。
⑵.Running Vusers
running vuser為場景運行時，正在運行的vuser情況。由於性能的問題由並發增大引起，所以，看其他指標需要結合running vuser情況。
現象：
起始為10個vuser，以10的階梯遞增，在1：36秒維持了3分鍾，而后以1個階梯減少；
分析：
需結合其他指標圖表。
⑶.Errors per Second (by Description)
每秒的錯誤數信息。可以查看隨着運行時間，不同錯誤的發生曲線。
現象：
在高並發時，前三個為突出的問題；Error 27728、27727出現在高並發階段；Error 17999 運行1分開始小幅波動，但具體什么錯誤不知道。
Error 27796：connection refused；
Error 26377：未找到關聯；
Error 26374：響應為空，可能導致了未找到關聯的錯誤；
Error 17999：message box處發生的錯誤；
Error 27728：step download timeout下載non-resource元素時，下載超時；
Error 27727：step download timeout下載resource元素時，下載超時；
前3個問題發生較多，中間有下降、上升的大幅波動，最后下降，呈M狀，3個問題的趨勢一致。
分析：
Error 27796：說明了，和服務端連接有問題；需要確定連接數是不是滿了，排查連接各環節的連接設置，看Connections圖；
Error 26377、26374：說明了，服務端未響應；進而需要看throughput、Average Transaction Response Time、transactions per second此類服務端性能的指標；
Error 17999：暫不清楚；
Error 27728 、27727：在高並發時才出現的下載超時的問題，應考慮服務端的處理能力；（如果場景開始就有下載超時，就需要檢查runtime setting-internet protocol中對超時時間的設置是不是太小了）
結合vuser圖，錯誤集中時段是並發數高於55個vuser 時間段，高並發導致了大量的error。系統目前性能情況，最大允許並發為55。
Error：連接拒絕
I．1 Hits per Second-Connections
連接數顯示了場景運行時，打開的http連接數。
根據上一步的推論，查看隨着vuser的增加，請求的增加，連接數是否達到了最大，因此導致了服務端拒絕訪問的問題。如果是這樣的情況則需要調整web服務端的最大連接數。
正常情況下，連接數的趨勢應該隨着vuser增加，請求增加，是逐步增加。但是此圖曲線有中間的下降，需要結合點擊率來較為准確的查看請求情況。
現象：
點擊率開始為增加趨勢，中間有降、升，而后波動，最后下降，基本呈M狀。
分析：
考慮到連接統計的延遲，連接數基本符合點擊率的波動情況，但是后面仍然保持在較高的連接數；
推論一、是否是因為連接未及時關閉，致使連接數滿了，繼而導致了服務端拒絕連接的問題；進而需要查看每秒的連接打開和關閉情況。
推論二、服務端、客戶端之間的連接數設置的過小，導致連接數滿了。
I．2 Connections per Second
顯示了在運行時，打開和關閉的http連接情況。如果連接關閉的曲線和連接打開的曲線差得多，表明連接未被及時關閉，連接被占用，會導致服務端連接的滿了，拒絕客戶端的訪問的錯誤。
現象：
曲線基本一致。
分析：
不是因為連接關閉不及時導致的連接數滿，服務端拒絕訪問的問題。所以根據上一步的推論二基本確定連接數設置問題，需要進一步查看web server、服務端操作系統連接數設置、客戶端操作系統連接設置、lr運行的設置等相關的連接數情況。
Error:服務端響應不過來
II. 1 Throughput
顯示場景運行時，每秒從服務端獲得的數據量，可以判斷服務器的處理能力。
現象：
吞吐量開始遞增，而后在高並發階段趨勢較平穩，最后下降。
分析：
服務端處理能力較為穩定，沒有發現問題。
II. 2 Hits per Second - Average Transaction Response Time
Average Transaction Response Time顯示場景運行時，事務執行所用的時間。事務的響應時間和請求數結合來看，查看check_itinerary事務響應時間。
現象：
兩個曲線在中間大幅下降后，后面波動的趨勢大致相符。
分析：
響應時間的降低是因為點擊率減少，服務端接收到的實際請求減少，壓力較小，響應快了。未分析出其他問題。
II. 3 Transaction per Second
顯示了事務的成功、失敗、停止的數量，通過此項可以確定系統在時間點的事務負載情況。和平均事務響應時間對比，可分析事務數對執行時間的影響。
現象：
check_itinerary成功的事務較波動，數值較小；check_itinerary失敗的事務集中時間為並發高峰時段。
分析：
TPS數值太小，說明了的服務端處理事務能力較弱，繼而需要查看system resource圖。
II. 4 System Resource
處理器的指標
現象：
Processor_total大部分在90%以上，表明cpu配置較低；
Interrupted/sec中斷並發高時較多，但低於60%；
Process_xiwin32較為平穩；推測為xiwin32進程（web server）；
Processor queue length cpu的平均負載很大；
分析：
系統cpu瓶頸較明顯，又考慮process_xiwin32占用cpu不算多。推測是由於系統服務端其他進程占中了大部分cpu。優化服務端的進程情況，使web服務更有效的占用cpu；或更換高配的cpu；或改為linux服務器，減少其他進程的占用。
內存的指標
現象： Private byte 隨並發請求增加，內存相應增加，后面下降。
分析：未發現問題。
磁盤的指標
現象： 隨着並發請求增加，磁盤交互響應增加，比較平穩；
分析： 未發現問題；
Transaction：check_itinerary
III.1 Web Page Diagnostics
此圖為對事務的各元素各種響應環節的細分情況。以下圖為check_itinerary的事務細分情況。
現象：
check_itinerary事務中itinerary.pl和sh_itinerary.gif的下載時間最長，請求itinerary.pl響應字節數較大，接收時間較長；sh_itinerary.gif並不大，但是first buffer time很長。
分析：
請求itinerary.pl的業務為查詢日程安排，推論是因為響應的數據量較大，導致的接收時間長。可以考慮優化該文件的代碼，拆分文件，壓縮輸出等。
sh_itinerary.gif文件 first buffer time較長，進而分析該項的time to first buffer情況。
First buffer time：
細分為服務端時間、網絡時間。
現象:
網絡時間明顯很大。
分析：
此文件的網絡時間較長，可推論出網絡方面的問題，需要進一步查看網絡指標確定。