原文：http://blog.sina.com.cn/s/blog_8216ada70100tyx3.html
LoadRunner生成測試結果並不代表着這次測試結果的結束，相反，這次測試結果的重頭戲才剛剛開始。如何對測試結果進行分析，關系着這次測試的成功與否。網上關於LoadRunner測試結果如何分析的介紹相當匱乏，在總結他人的觀點和自己的實驗體會基礎上來介紹如何進行LoadRunner測試結果分析。
1. LoadRunner測試結果分析的第一步應該是查看分析綜述（Analysis Summary），其包括統計綜述（Statistics Summary）、事務綜述（Transaction Summary）、HTTP 響應綜述（HTTP Responses Summary）三部分。在統計綜述中查看Total Errors的數量，HTTP 響應綜述中查看HTTP 404數量，若數值相對較大（HTTP 404則相對於HTTP 200），則說明系統測試中出錯較多，系統系能有問題；另外查看事務的平均響應時間和其90%的事務平均響應時間，若時間過長，超過測試計划中的要求值，則說明系統的性能不滿足我們的要求。
2. 第二步對LoadRunner測試結果圖進行分析，首先對事務綜述（Transaction Summary）進行分析，該圖可以直觀地看出在測試時間內事務的成功與失敗情況，所以比第一步更容易判斷出被測系統運行是否正常。
3. 接着分析事務平均響應時間（Average Transaciton Response Time），若事務平均響應時間曲線趨高，則說明被測系統處理事務的速度開始逐漸變慢，即被測系統隨着運行時間的變化，整體性能不斷下降。當系統性能存在問題時，該曲線的走向一般表現為開始緩慢上升，然后趨於平穩，最后緩慢下降。原因是：被測系統處理事務能力下降，事務平均響應時間變長，在曲線上表現為緩慢上升；而並發事務達到一定數量時，被測系統無法處理多余的事務，此時曲線變現為趨於平穩；當一段時間后，事務不斷被處理，其數量減少，在曲線上表現為下降。如果被測系統沒有等待機制，那么事務響應時間會越來越長，最后系統崩潰。
4. 再分析每秒通過事務數（Transactions per Second/TPS），該曲線表示被測系統在運行的任意時刻，每個事務通過、失敗的情況，其是考查系統性能的一個重要參數。若隨着壓力的增加，曲線如果開始變化緩慢或有平穩的趨勢，則有可能是服務器開始出現瓶頸。
[5]. 分析每秒通過事務總數（Total Transactions per Second），該曲線顯示在任意時刻被測系統通過的事務總數、失敗的事務總數。該曲線走向和TPS曲線走向一致。
[6]. 事務性能摘要（Transaction Performance Sunmmary）該曲線表示被測系統中所有事務的最小、最大和平均事務響應時間。
[7]. 事務在負載情況下的響應時間（Transaction Response Time Under Load），該曲線表示在不同數量的虛擬用戶情況下的事務響應時間情況。該圖對分析具有漸變負載的測試場景比較有用。
[8]. 事務響應時間（百分比）（Transaction Response Time（Percentile）），該曲線可以容易地分析出在給定的響應時間范圍內事務量的百分比重。
[9]. 事務響應時間（分布）（Transaction Response Time(Distribution)），該圖可以容易地分析出在給定響應時間范圍內的事務量情況。
其實，若並不是十分詳細地分析測試結果，第4步與第5步選其一分析，第6步、第7步、第8步為可選項，因為在第1步就在一定程度上分析了，而第9步又與第8步功能相識。LoadRunner生成測試結果圖在很大的程度上具有一定的重復性，只不過是在不同情況下的具體顯示。
以下內容原文：http://www.testwo.com/blog/5466
Duration(持續時間)：了解該測試過程持續時間。測試人員本身要對這個時期內系統一共做了多少的事有大致的熟悉了解.以確定下次增加更多的任務條件下測試的持續時間。
Statistics Summary(統計摘要)：只是大概了解一下測試數據，對我們具體分析沒有太大的作用.
Transaction Summary(事務摘要)：了解平均響應時間Average單位為秒。
其余的看不看都可以，都不是很重要。
4、分析集合點
在錄制腳本中通常我們會使用到集合點，那么既然我們用到了集合點，我們就需要知道Vuser是在什么時候集合在這個點上，又是怎樣的一個被釋放的過程。這個時候就需要觀察Vuser-Rendezvous圖。
圖1
可以看到大概在3分50的地方30個用戶才全部集中到start集合點，持續了3分多，在7分30的位置開始釋放用戶，9分30還有18個用戶，11分10還有5個用戶，整個過程持續了12分。
圖2
上面圖2是集合點與平均事務響應時間的比較圖。
注：在打開analysis之后系統LR默認這兩個曲線是不在同一張圖中的。這就需要自行設置了。具體步驟如下:
點擊圖上，右鍵選擇merge graphs，然后在select graph to merge with中選擇即將用來進行比較的graph。如圖3：
圖3
圖2中較深顏色的是平均響應時間，淺色的為集合點，當Vuser在集合點持續了1分后平均響應時間呈現最大值，可見用戶的並發對系統的性能是一個很大的考驗。
接下來看一下與事務有關的參數分析。看下一張圖。
圖4
這張圖包括Average Transaction Response Time和Running Vuser兩個數據圖。從圖中可以看到Vuser_init_Transaction(系統登錄)對系統無任何的影響，Vuser達到15個的時候平均事務響應時間才有明顯的升高，也就是說系統達到最優性能的時候允許14個用戶同時處理事務，Vuser達到30后1分，系統響應時間最大，那么這個最大響應時間是要推遲1分鍾才出現的，在系統穩定之后事務響應時間開始下降說明這個時候有些用戶已經執行完了操作。同時也可以看出要想將事務響應時間控制在10S內，Vuser數量最多不能超過2個，看來是很難滿足用戶的需求了。
做一件事有時候上級會問你這件事辦得怎么樣了，你會說做完一半了，那么這個一半的事情你花了多少時間呢？所以我們要想知道在給定時間的范圍內完成事務的百分比就要靠下面這個圖(Transaction Response Time(Percentile))
圖中畫圈的地方表示10%的事務響應時間是在80S左右。80S對於用戶來說不是一個很小的數字，而且只有10%的事務，汗！你覺得這個系統性能會好么！
實際工作中遇到的事情不是每一件事都能夠在很短的時間內完成的，對於那些需要時間的事情我們就要分配適當的時間處理，時間分配的不均勻就會出現有些事情消耗的時間長一些，有些事情消耗的短一些，但我們自己清楚LR同樣也為我們提供了這樣的功能，使我們可以了解大部分的事務響應時間是多少，以確定這個系統我們還要付出多少的代價來提高它。
Transaction Response Time(Distribution)-事務響應時間(分布)
顯示在方案中執行事務所用時間的分布。如果定義了可以接受的最小和最大事務性能時間，可以通過此圖確定服務器性能是否在可接受范圍內。
很明顯大多數事務的響應時間在60-140S。在我測試過的項目中多數客戶所能接受的最大響應時間也要在20S左右。140S的時間很少有人會去花這么多的時間去等待頁面的出現吧！
通過觀察以上的數據表，我們不難看到此系統在這種環境下並不理想。世間事有果就有因，那么是什么原因導致得系統性能這樣差呢？讓我們一步一步的分析。
系統性能不好的原因多方面，我們先從應用程序看，有的時候我不得不承認LR的功能真的很強大，這也是我喜歡它的原因。先看一張頁面細分圖。
一個應用程序是由很多個組件組成的，整個系統性能不好那我們就把它徹底的剖析一下。圖片中顯示了整個測試過程中涉及到的所有web頁。web page breakdown中顯示的是每個頁面的下載時間。點選左下角web page breakdown展開，可以看到每個頁中包括的css樣式表，js腳本，jsp頁面等所有的屬性。在select page to breakdown中選擇頁面。見圖。
在Select Page To Breakdown 中選擇http://192.168.0.135:8888/usertasks后，在下方看到屬於它的兩個組件，第一行中Connection和First Buffer占據了整個的時間，那么它的消耗時間點就在這里，我們解決問題就要從這里下手。
| 名稱 |
描述 |
|
|
顯示使用最近的 DNS 服務器將 DNS 名稱解析為 IP 地 址所需的時間。“DNS 查找”度量是指示 DNS 解析問 題或 DNS 服務器問題的一個很好的指示器。 |
|
|
顯示與包含指定 URL 的 Web 服務器建立初始連接所需 的時間。連接度量是一個很好的網絡問題指示器。此 外，它還可表明服務器是否對請求作出響應。 |
|
|
顯示從初始 HTTP 請求（通常為 GET）到成功收回來 自 Web 服務器的第一次緩沖時為止所經過的時間。第 一次緩沖度量是很好的 Web 服務器延遲和網絡滯后指 示器。 注意：由於緩沖區大小最大為 8K，因此第一次緩沖時 間可能也就是完成元素下載所需的時間。 |
|
|
顯示建立 SSL 連接（包括客戶端 hello、服務器 hello、客戶端公用密鑰傳輸、服務器證書傳輸和其他 部分可選階段）所用的時間。自此點之后，客戶端與服 務器之間的所有通信都將被加密。 SSL 握手度量僅適用於 HTTPS 通信。 |
|
|
顯示從服務器收到最后一個字節並完成下載之前經過的 時間。 “接收”度量是很好的網絡質量指示器（查看用來計算 接收速率的時間/ 大小比率）。 |
|
|
顯示驗證客戶端所用的時間。如果使用 FTP，則服務器 在開始處理客戶端命令之前，必須驗證該客戶端。 “FTP 驗證”度量僅適用於 FTP 協議通信。 |
|
|
顯示因瀏覽器思考時間或其他與客戶端有關的延遲而使 客戶機上的請求發生延遲時，所經過的平均時間。 |
|
|
顯示從發出 HTTP 請求到返回錯誤消息（僅限於 HTTP 錯誤）這期間經過的平均時間。 |
也有可能你的程序中client的時間最長，或者其他的，這些就要根據你自己的測試結果來分析了。下面我們來看一下CPU、內存、硬盤的瓶頸分析方法：
首先我們要監視CPU、內存、硬盤的資源情況，得到以下的參數提供分析的依據。
%processor time(processor_total):消耗的處理器時間數量，如果服務器專用於sql server可接受的最大上限是80% -85 %.也就是常見的CPU使用率。
%User time(processor_total):表示耗費CPU的數據庫操作，如排序、執行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯接，水平分割大表格等方法來降低該值。
%DPC time(processor_total):越低越好。在多處理器系統中，如果這個值大於50%並且Processor:% Processor Time非常高，加入一個網卡可能會提高性能，提供的網絡已經不飽和。
%Disk time(physicaldisk_total):指所選磁盤驅動器忙於為讀或寫入請求提供服務所用的時間的百分比。如果三個計數器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數器之前，請在Windows 2000 的命令行窗口中運行diskperf -yD。若數值持續超過80%，則可能是內存泄漏。
Availiable bytes(memory):用物理內存數. 如果Available Mbytes的值很小（4 MB 或更小），則說明計算機上總的內存可能不足，或某程序沒有釋放內存。
Context switch/sec(system): (實例化inetinfo 和dllhost 進程) 如果你決定要增加線程字節池的大小，你應該監視這三個計數器（包括上面的一個）。增加線程數可能會增加上下文切換次數，這樣性能不會上升反而會下降。如果十個實例的上下文切換值非常高，就應該減小線程字節池的大小。
%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 的開銷大，可以通過使用更大的數據高速緩存、智能索引、更高效的查詢或者改變數據庫設計等方法，使開銷減到最小。
Page write/sec:(寫的頁/秒)每秒執行的物理數據庫寫的頁數。
1、判斷應用程序的問題
如果系統由於應用程序代碼效率低下或者系統結構設計有缺陷而導致大量的上下文切換(context switches/sec顯示的上下文切換次數太高)那么就會占用大量的系統資源，如果系統的吞吐量降低並且CPU的使用率很高，並且此現象發生時切換水平在15000以上，那么意味着上下文切換次數過高。
從圖的整體看context switches/sec變化不大，throughout曲線的斜率較高，並且此時的context switches/sec已經超過了15000。程序還是需要進一步優化。
2、判斷CPU瓶頸
如果processor queue length顯示的隊列長度保持不變(>=2)個並且處理器的利用率%Processor time超過90%，那么很可能存在處理器瓶頸。如果發現processor queue length顯示的隊列長度超過2，而處理器的利用率卻一直很低，或許更應該去解決處理器阻塞問題，這里處理器一般不是瓶頸。
%processor time平均值大於95，processor queue length大於2，可以確定CPU瓶頸，此時的CPU已經不能滿足程序需要，急需擴展。
3、判斷內存泄露問題
內存問題主要檢查應用程序是否存在內存泄漏，如果發生了內存泄漏，process\private bytes計數器和process\working set 計數器的值往往會升高，同時avaiable bytes的值會降低。內存泄漏應該通過一個長時間的用來研究分析所有內存都耗盡時，應用程序反應情況的測試來檢驗。
圖中可以看到該程序並不存在內存泄露的問題，內存泄露問題經常出現在服務長時間運轉的時候，由於部分程序對內存沒有釋放，而將內存慢慢耗盡。也是提醒大家對系統穩定性測試的關注。
Duration(持續時間)：了解該測試過程持續時間。測試人員本身要對這個時期內系統一共做了多少的事有大致的熟悉了解.以確定下次增加更多的任務條件下測試的持續時間。
Statistics Summary(統計摘要)：只是大概了解一下測試數據，對我們具體分析沒有太大的作用.
Transaction Summary(事務摘要)：了解平均響應時間Average單位為秒。
其余的看不看都可以，都不是很重要。
4、分析集合點
在錄制腳本中通常我們會使用到集合點，那么既然我們用到了集合點，我們就需要知道Vuser是在什么時候集合在這個點上，又是怎樣的一個被釋放的過程。這個時候就需要觀察Vuser-Rendezvous圖。
圖1
可以看到大概在3分50的地方30個用戶才全部集中到start集合點，持續了3分多，在7分30的位置開始釋放用戶，9分30還有18個用戶，11分10還有5個用戶，整個過程持續了12分。
圖2
上面圖2是集合點與平均事務響應時間的比較圖。
注：在打開analysis之后系統LR默認這兩個曲線是不在同一張圖中的。這就需要自行設置了。具體步驟如下:
點擊圖上，右鍵選擇merge graphs，然后在select graph to merge with中選擇即將用來進行比較的graph。如圖3：
圖3
圖2中較深顏色的是平均響應時間，淺色的為集合點，當Vuser在集合點持續了1分后平均響應時間呈現最大值，可見用戶的並發對系統的性能是一個很大的考驗。
接下來看一下與事務有關的參數分析。看下一張圖。
圖4
這張圖包括Average Transaction Response Time和Running Vuser兩個數據圖。從圖中可以看到Vuser_init_Transaction(系統登錄)對系統無任何的影響，Vuser達到15個的時候平均事務響應時間才有明顯的升高，也就是說系統達到最優性能的時候允許14個用戶同時處理事務，Vuser達到30后1分，系統響應時間最大，那么這個最大響應時間是要推遲1分鍾才出現的，在系統穩定之后事務響應時間開始下降說明這個時候有些用戶已經執行完了操作。同時也可以看出要想將事務響應時間控制在10S內，Vuser數量最多不能超過2個，看來是很難滿足用戶的需求了。
做一件事有時候上級會問你這件事辦得怎么樣了，你會說做完一半了，那么這個一半的事情你花了多少時間呢？所以我們要想知道在給定時間的范圍內完成事務的百分比就要靠下面這個圖(Transaction Response Time(Percentile))
圖中畫圈的地方表示10%的事務響應時間是在80S左右。80S對於用戶來說不是一個很小的數字，而且只有10%的事務，汗！你覺得這個系統性能會好么！
實際工作中遇到的事情不是每一件事都能夠在很短的時間內完成的，對於那些需要時間的事情我們就要分配適當的時間處理，時間分配的不均勻就會出現有些事情消耗的時間長一些，有些事情消耗的短一些，但我們自己清楚LR同樣也為我們提供了這樣的功能，使我們可以了解大部分的事務響應時間是多少，以確定這個系統我們還要付出多少的代價來提高它。
Transaction Response Time(Distribution)-事務響應時間(分布)
顯示在方案中執行事務所用時間的分布。如果定義了可以接受的最小和最大事務性能時間，可以通過此圖確定服務器性能是否在可接受范圍內。
很明顯大多數事務的響應時間在60-140S。在我測試過的項目中多數客戶所能接受的最大響應時間也要在20S左右。140S的時間很少有人會去花這么多的時間去等待頁面的出現吧！
通過觀察以上的數據表，我們不難看到此系統在這種環境下並不理想。世間事有果就有因，那么是什么原因導致得系統性能這樣差呢？讓我們一步一步的分析。
系統性能不好的原因多方面，我們先從應用程序看，有的時候我不得不承認LR的功能真的很強大，這也是我喜歡它的原因。先看一張頁面細分圖。
一個應用程序是由很多個組件組成的，整個系統性能不好那我們就把它徹底的剖析一下。圖片中顯示了整個測試過程中涉及到的所有web頁。web page breakdown中顯示的是每個頁面的下載時間。點選左下角web page breakdown展開，可以看到每個頁中包括的css樣式表，js腳本，jsp頁面等所有的屬性。在select page to breakdown中選擇頁面。見圖。
在Select Page To Breakdown 中選擇http://192.168.0.135:8888/usertasks后，在下方看到屬於它的兩個組件，第一行中Connection和First Buffer占據了整個的時間，那么它的消耗時間點就在這里，我們解決問題就要從這里下手。
| 名稱 |
描述 |
|
|
顯示使用最近的 DNS 服務器將 DNS 名稱解析為 IP 地 址所需的時間。“DNS 查找”度量是指示 DNS 解析問 題或 DNS 服務器問題的一個很好的指示器。 |
|
|
顯示與包含指定 URL 的 Web 服務器建立初始連接所需 的時間。連接度量是一個很好的網絡問題指示器。此 外，它還可表明服務器是否對請求作出響應。 |
|
|
顯示從初始 HTTP 請求（通常為 GET）到成功收回來 自 Web 服務器的第一次緩沖時為止所經過的時間。第 一次緩沖度量是很好的 Web 服務器延遲和網絡滯后指 示器。 注意：由於緩沖區大小最大為 8K，因此第一次緩沖時 間可能也就是完成元素下載所需的時間。 |
|
|
顯示建立 SSL 連接（包括客戶端 hello、服務器 hello、客戶端公用密鑰傳輸、服務器證書傳輸和其他 部分可選階段）所用的時間。自此點之后，客戶端與服 務器之間的所有通信都將被加密。 SSL 握手度量僅適用於 HTTPS 通信。 |
|
|
顯示從服務器收到最后一個字節並完成下載之前經過的 時間。 “接收”度量是很好的網絡質量指示器（查看用來計算 接收速率的時間/ 大小比率）。 |
|
|
顯示驗證客戶端所用的時間。如果使用 FTP，則服務器 在開始處理客戶端命令之前，必須驗證該客戶端。 “FTP 驗證”度量僅適用於 FTP 協議通信。 |
|
|
顯示因瀏覽器思考時間或其他與客戶端有關的延遲而使 客戶機上的請求發生延遲時，所經過的平均時間。 |
|
|
顯示從發出 HTTP 請求到返回錯誤消息（僅限於 HTTP 錯誤）這期間經過的平均時間。 |
也有可能你的程序中client的時間最長，或者其他的，這些就要根據你自己的測試結果來分析了。下面我們來看一下CPU、內存、硬盤的瓶頸分析方法：
首先我們要監視CPU、內存、硬盤的資源情況，得到以下的參數提供分析的依據。
%processor time(processor_total):消耗的處理器時間數量，如果服務器專用於sql server可接受的最大上限是80% -85 %.也就是常見的CPU使用率。
%User time(processor_total):表示耗費CPU的數據庫操作，如排序、執行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡單的表聯接，水平分割大表格等方法來降低該值。
%DPC time(processor_total):越低越好。在多處理器系統中，如果這個值大於50%並且Processor:% Processor Time非常高，加入一個網卡可能會提高性能，提供的網絡已經不飽和。
%Disk time(physicaldisk_total):指所選磁盤驅動器忙於為讀或寫入請求提供服務所用的時間的百分比。如果三個計數器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數器之前，請在Windows 2000 的命令行窗口中運行diskperf -yD。若數值持續超過80%，則可能是內存泄漏。
Availiable bytes(memory):用物理內存數. 如果Available Mbytes的值很小（4 MB 或更小），則說明計算機上總的內存可能不足，或某程序沒有釋放內存。
Context switch/sec(system): (實例化inetinfo 和dllhost 進程) 如果你決定要增加線程字節池的大小，你應該監視這三個計數器（包括上面的一個）。增加線程數可能會增加上下文切換次數，這樣性能不會上升反而會下降。如果十個實例的上下文切換值非常高，就應該減小線程字節池的大小。
%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 的開銷大，可以通過使用更大的數據高速緩存、智能索引、更高效的查詢或者改變數據庫設計等方法，使開銷減到最小。
Page write/sec:(寫的頁/秒)每秒執行的物理數據庫寫的頁數。
1、判斷應用程序的問題
如果系統由於應用程序代碼效率低下或者系統結構設計有缺陷而導致大量的上下文切換(context switches/sec顯示的上下文切換次數太高)那么就會占用大量的系統資源，如果系統的吞吐量降低並且CPU的使用率很高，並且此現象發生時切換水平在15000以上，那么意味着上下文切換次數過高。
從圖的整體看context switches/sec變化不大，throughout曲線的斜率較高，並且此時的context switches/sec已經超過了15000。程序還是需要進一步優化。
2、判斷CPU瓶頸
如果processor queue length顯示的隊列長度保持不變(>=2)個並且處理器的利用率%Processor time超過90%，那么很可能存在處理器瓶頸。如果發現processor queue length顯示的隊列長度超過2，而處理器的利用率卻一直很低，或許更應該去解決處理器阻塞問題，這里處理器一般不是瓶頸。
%processor time平均值大於95，processor queue length大於2，可以確定CPU瓶頸，此時的CPU已經不能滿足程序需要，急需擴展。
3、判斷內存泄露問題
內存問題主要檢查應用程序是否存在內存泄漏，如果發生了內存泄漏，process\private bytes計數器和process\working set 計數器的值往往會升高，同時avaiable bytes的值會降低。內存泄漏應該通過一個長時間的用來研究分析所有內存都耗盡時，應用程序反應情況的測試來檢驗。
圖中可以看到該程序並不存在內存泄露的問題，內存泄露問題經常出現在服務長時間運轉的時候，由於部分程序對內存沒有釋放，而將內存慢慢耗盡。也是提醒大家對系統穩定性測試的關注。