1、性能測試工程師基本上都能夠掌握利用測試工具來作負載、 壓力測試， 但多數人對怎樣去分 析工具收集到的測試結果感到無從下手， 下面我就把個人工作中的體會和收集到的有關資料 整理出來，希望能對大家分析測試結果有所幫助。 分析原則：1. 具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）2. 查找瓶頸時按以下順序，由易到難。服務器硬件瓶頸 -網絡瓶頸（對局域網，可以不考慮）-服務器操作系統瓶頸（參數配置） -中間件瓶頸（參數配置，數據庫， web 服務器等） -應用瓶頸（ SQL 語句、數據 庫設計、業務邏輯、算法等）注：以上過程并不是每個分析中都需要的，要根據測試目的和要

2、求來確定分析的深度。 對一些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系 統的硬件瓶頸在哪兒就夠了。3 分段排除法 很有效分析的信息來源：1 根據場景運行過程中的錯誤提示信息2 根據測試結果收集到的監控指標數據一錯誤提示分析分析實例：1 Error: Failed to connect to server "0:8080" : 10060 Conn ectionError: timed out Error: Server " 0" has shut dow n the connecti

3、on prematurely 分析：A 、應用服務死掉。（小用戶時：程序上的問題。程序上處理數據庫的問題）B、應用服務沒有死（應用服務參數設置問題）例：在許多客戶端連接 Weblogic 應用服務器被拒絕，而在服務器端沒有錯誤顯示，則 有可能是 Weblogic 中的 server 元素的 AcceptBacklog 屬性值設得過低。如果連接時收到 connection refused 消息，說明應提高該值，每次增加 25C、數據庫的連接（1、在應用服務的性能參數可能太小了2、數據庫啟動的最大連接數 （跟硬件的內存有關） ）2 Error: Page download timeout （120

4、 seconds） has expired 分析：可能是以下原因造成A 、應用服務參數設置太大導致服務器的瓶頸B、頁面中圖片太多C、在程序處理表的時候檢查字段太大多二監控指標數據分析1最大并發用戶數： 應用系統在當前環境(硬件環境、網絡環境、軟件環境(參數配置) )下能承受的最大并發 用戶數。在方案運行中，如果出現了大于 3 個用 戶的業務操作失敗，或出現了服務器 shutdown 的情況，則說明在當前環境下，系統承受不 了當前并發用戶的負載壓力， 那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶 數。如果測得的最大并發用戶數到達了性能要求， 且各服務器資源情況良好， 業務操作響應 時間

5、也達到了用戶要求，那么 OK 。否則，再根據各服務器的資源情況和業務操作響應時間 進一步分析原因所在。2業務操作響應時間： 分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用“事務性能 摘要”圖，可以確定在方案執行期間響應時間過長的事務。細分事務并分析每個頁面組件的性能。 查看過長的事務響應時間是由哪些頁面組件引起 的？問題是否與網絡或服務器有關？如果服務器耗時過長， 請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能 下降的原因。如果網絡耗時過長，請使用“網絡監視器”圖確定導致性能瓶頸的網絡問題3服務器資源監控指標：內存：1 UNIX資源監控中指標內存頁交換速率( Pa

6、ging rate),如果該值偶爾走高，表明當時有線 程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。2 Windows 資源監控中, 如果 ProcessPrivate Bytes 計數器和 ProcessWorking Set 計數器的值 在長時間內持續升高,同時 MemoryAvailable bytes 計數器的值持續降低,則很可能存在內 存泄漏。內存資源成為系統性能的瓶頸的征兆 : 很高的換頁率 (high pageout rate);進程進入不活動狀態 ; 交換區所有磁盤的活動次數可高 ;可高的全局系統 CPU 利用率 ; 內存不夠出錯 (out of mem

7、ory errors)處理器：1 UNIX 資源監控( Windows 操作系統同理)中指標 CPU 占用率( CPU utilization )，如果該 值持續超過95%，表明瓶頸是 CPU。可以考慮增加一個處理器或換一個更快的處理器。如 果服務器專用于 SQL Server,可接受的最大上限是80-85%合理使用的范圍在 60%至 70%。2 Windows 資源監控中，如果 SystemProcessor Queue Length 大于 2，而處理器利用率(Processor Time)直很低，則存在著處理器阻塞。CPU 資源成為系統性能的瓶頸的征兆 :很慢的響應時間 (slow res

8、ponse time)CPU 空閑時間為零 (zero percent idle CPU)過高的用戶占用 CPU 時間 (high percent user CPU) 過高的系統占用 CPU 時間 (high percent system CPU) 長時間的有很長的運行進程隊列 (large run queue size sustained over time)磁盤 I/O ：1 UNIX 資源監控( Windows 操作系統同理)中指標磁盤交換率( Disk rate) ，如果該參數值 一直很高，表明 I/O 有問題。可考慮更換更快的硬盤系統。2 Windows 資源監控中，如果 Disk

9、Time 和 Avg.Disk Queue Length 的值很高，而 Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。I/O 資源成為系統性能的瓶頸的征兆 : 過高的磁盤利用率 (high disk utilization) 太長的磁盤等待隊列 (large disk queue length) 等待磁盤 I/O 的時間所占的百分率太高 (large percentage of time waiting for disk I/O) 太高的物理 I/O 速率 :large physical I/O rate(not sufficient in itself) 過低的緩存命

10、中率 (low buffer cache hit ratio(not sufficient in itself) 太長的運行進程隊列，但 CPU 卻空閑 (large run queue with idle CPU)4數據庫服務器：SQL Server 數據庫：1 SQLServer 資源監控中指標緩存點擊率( Cache Hit Ratio )，該值越高越好。如果持續低于 80%，應考慮增加內存。2如果Full Scans/sec(全表掃描/秒)計數器顯示的值比1或2高，則應分析你的查詢以確定是否確實需要全表掃描，以及 SQL 查詢是否可以被優化。3 Number of Deadlocks/

11、sec(死鎖的數量/秒):死鎖對應用程序的可伸縮性非常有害，并且會導致惡劣的用戶體驗。該計數器的值必須為0。4 Lock Requests/sec(鎖請求/秒)，通過優化查詢來減少讀取次數，可以減少該計數器的值。Oracle 數據庫:1 如果自由內存接近于 0 而且庫快存或數據字典快存的命中率小于 0.90，那么需要增加 SHARED_POOL_SIZE 的大小。快存(共享 SQL 區)和數據字典快存的命中率:select(sum(pins-reloads)/sum(pins) from v$librarycache;select(sum(gets-getmisses)/sum(gets) f

12、rom v$rowcache;自由內存：select * from v$sgastat where name= 'free memory ' ;2 如果數據的緩存命中率小于0.90，那么需要加大 DB_BLOCK_BUFFERS 參數的值 (單位：塊)。緩沖區高速緩存命中率：select name,value from v$sysstat where name in (?db block gets?, consistent gets?,'physical reads?) ;Hit Ratio = 1-(physical reads / ( db block gets +

13、 consistent gets)3 如果日志緩沖區申請的值較大，則應加大 LOG_BUFFER 參數的值。 日志緩沖區的申請情況 ：select name,value from v$sysstat where name = ,redo log space requests? ;4 如果內存排序命中率小于 0.95，則應加大 SORT_AREA_SIZE 以避免磁盤排序 內存排序命中率 ：select round(100*b.value)/decode(a.value+b.value), 0, 1, (a.value+b.value), 2)from v$sysstat a, v$syssta

14、t b where =?sorts (disk)? and =?sorts (memory)?注：上述 SQL Server 和 Oracle 數據庫分析，只是一些簡單、基本的分析，特別是 Oracle 數 據庫的分析和優化，是一門專門的技術，進一步的分析可查相關資料。性能測試的結果分析是性能測試的重中之重。在實際工作中，由于測試的結果分析比較復雜、需要具備很多相關的專業知識， 因此常常會感覺拿到數據不知從何下手。 這也是我學習 性能測試過程中感覺比較尷尬和棘手的事，為此我在研讀了 WEB 性能測試實戰后特作了以 下筆記，這里只是書中第 4 章 WEB 應用程序性能分析

15、的一部分，貼出來希望和大家共同討論：性能分析的基礎知識：1幾個重要的性能指標：相應時間、吞吐量、吞吐率、TPS （每秒鐘處理的交易數）、點擊率等。2. 系統的瓶頸分為兩類：網絡的和服務器的。服務器瓶頸主要涉及：應用程序、WEB 服務器、數據庫服務器、操作系統四個方面。3. 常規、粗略的性能分析方法：當增大系統的壓力（或增加并發用戶數）時，吞吐率和 TPS 的變化曲線呈大體一致，則 系統基本穩定； 若壓力增大時，吞吐率的曲線增加到一定程度后出現變化緩慢， 甚至平坦， 很可 能是網絡出現帶寬瓶頸，同理若點擊率 /TPS 曲線出現變化緩慢或者平坦，說明服務器開始出現 頸。4. 作者提出了如下的性能分

16、析基本原則，此原則本人十分贊同：由外而內、由表及里、層層深入應用此原則，分析步驟具體可以分為以下三步： 第一步：將得到的響應時間和用戶對性能的期望值比較確定是否存在瓶頸；第二步：比較Tn （網絡響應時間）和 Ts （服務器響應時間）可以確定瓶頸發生在網絡還 是服務器；第三步：進一步分析，確定更細組件的響應時間，直到找出發生性能瓶頸的根本原因。以 WEB 應用程序為例來看下具體的分析方法：1.用戶事務分析：a. 事務綜述圖(Transaction Summary ):以柱狀圖的形式表現了用戶事務執行的成功與失敗。通過分析成功與失敗的數據可以直接判斷出系統是否運行正常。 若失敗的事務非常多， 則說

17、明系統發生了瓶頸或者程序在執行過程中發生了問題。b. 事務平均響應時間分析圖( Average Transaction Response Time):該圖顯示在測試場景運行期間的每一秒內事務執行所用的平均時間， 還顯示了測試場景運行時間內各個 事務的最大值、 最小值和平均值。 通過它可以分析系統的性能走向。 若所有事務響應時間基本成 一條曲線， 則說明系統性能基本穩定； 否則如果平均事務響應時間逐漸變慢， 說明性能有下降趨 勢，造成性能下降的原因有可能是由于內存泄漏導致。c. 每秒通過事務數分析圖(Transaction per Second即TPS):顯示在場景運行的每一秒中，每個事 務通過

18、、失敗以及停止的數量。通過它可以確定系統在任何給定時刻的實際事務負載。 若隨著測試的進展， 應用系統在單位時間內通過的事務數目在減少， 則說明服務器出現瓶頸。d. 每秒通過事務總數分析圖( Total Transactions per Second):顯示場景運行的每一秒中，通過、失敗以及停止的事務總數。若在同等壓力下，曲線接近直線，則性能基本趨于穩定； 若在單位時間內通過的事務總量越來越少， 即整體性能下降。 原因可能是內存泄漏或 者程序中的缺陷。e. 事務性能摘要圖(Transaction Performanee Summary):顯示方案中所有事務的最小、最大平均執行時間，可以直接判斷響

19、應時間是否符合客戶要求(重點關注事務平均、 最大執行時間)。f. 事務響應時間與負載分析圖(Transaction Response Time Under load):通過該圖可以看出在任一時間點事務響應時間與用戶數目的關系， 從而掌握系統在用戶并發方面 的性能數據。g. 事務響應時間(百分比)圖(Transaction Response Time(percentile):該圖是根據測試結果進行分析而得到的綜合分析圖。 分析該圖應從整體出發， 若可能事務的最 大響應時間很長，但如果大多數事務具有可接受的響應時間，則系統的性能是符合。h. 事務響應時間分布情況圖(Transaction Resp

20、onse Time (Distribution):該圖顯示了測試過程中不同響應時間的事務數量。 若系統預先定義了相關事務可以接受的最小 和最大事務響應時間，則可以使用此圖確定系統性能是否在接受范圍內。分析到這一步，只能大概判斷出瓶頸可能會出在那，要具體定位瓶頸還需要更深入的分析。沒有貼圖，看起來有點費勁，如果你對這些圖都比較了解，應該是比較簡單的分析原則：? 具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）? 查找瓶頸時按以下順序，由易到難。服務器硬件瓶頸 -網絡瓶頸（對局域網，可以不考慮）-服務器操作系統瓶頸（參數配置） -中間件瓶頸（參數配置，數據庫，web 服

21、務器等） -應用瓶頸（ SQL 語句、數據庫設計、業務邏輯、算法等） 注：以上過程并不是每個分析中都需要的， 要根據測試目的和要求來確定分析的深度。 對一 些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系統的 硬件瓶頸在哪兒就夠了。? 分段排除法 很有效 分析的信息來源： ?1 根據場景運行過程中的錯誤提示信息 ?2 根據測試結果收集到的監控指標數據 一錯誤提示分析 分析實例：1 ?Error: Failed to connect to server“ " : 10060 Connection?Error: timed out Error: Server“

22、 " has shut down the connection prematurely分析：?A、應用服務死掉。（小用戶時：程序上的問題。程序上處理數據庫的問題）?B、應用服務沒有死 （應用服務參數設置問題）例：在許多客戶端連接 Weblogic 應用服務器被拒絕，而在服務器端沒有錯誤顯示，則有 可能是 Weblogic 中的 server 元素的 AcceptBacklog 屬性值設得過低。如果連接時收到 connection refused 消息，說明應提高該值，每次增加 25?C、數據庫的連接（1、在應用服務的性能參數可能太小了 2、數據庫啟動的最大連接數 （跟硬件的內存有關）

23、 ）2 Error: Page download timeout （120 seconds） has expired 分析：可能是以下原因造成?A、應用服務參數設置太大導致服務器的瓶頸?B、頁面中圖片太多?C 、在程序處理表的時候檢查字段太大多 二監控指標數據分析1最大并發用戶數： 應用系統在當前環境（硬件環境、網絡環境、軟件環境（參數配置） ）下能承受的最大并發 用戶數。在方案運行中，如果出現了大于 3 個用戶的業務操作失敗，或出現了服務器 shutdown 的 情況， 則說明在當前環境下， 系統承受不了當前并發用戶的負載壓力， 那么最大并發用戶數 就是前一個沒有出現這種現象的并發用戶數。如

24、果測得的最大并發用戶數到達了性能要求，且各服務器資源情況良好，業務操作響應 時間也達到了用戶要求，那么 OK 。否則，再根據各服務器的資源情況和業務操作響應時間進一步分析原因所在。2業務操作響應時間：? 分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用 “事務性能摘 要”圖，可以確定在方案執行期間響應時間過長的事務。? 細分事務并分析每個頁面組件的性能。查看過長的事務響應時間是由哪些頁面組件引起 的？問題是否與網絡或服務器有關？? 如果服務器耗時過長， 請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能 下降的原因。如果網絡耗時過長，請使用 “網絡監視器 ”圖確定導致性

25、能瓶頸的網絡問題2-5-10 原則：簡單說，就是當用戶能夠在 2 秒以內得到響應時，會感覺系統的響應很快；當 用戶在 2-5 秒之間得到響應時，會感覺系統的響應速度還可以；當用戶在5-10 秒以內得到響應時，會感覺系統的響應速度很慢，但是還可以接受；而當用戶在超過10 秒后仍然無法得到響應時，會感覺系統糟透了，或者認為系統已經失去響應，而選擇離開這個 Web 站點， 或者發起第二次請求3服務器資源監控指標：內存：1 UNIX 資源監控中指標內存頁交換速率(Paging rate )，如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。2 Wind

26、ows 資源監控中， 如果 ProcessPrivate Bytes 計數器和 ProcessWorking Set 計數器的值 在長時間內持續升高，同時 MemoryAvailable bytes 計數器的值持續降低，則很可能存在內 存泄漏。內存資源成為系統性能的瓶頸的征兆 :很高的換頁率 (high pageout rate);進程進入不活動狀態 ; 交換區所有磁盤的活動次數可高 ;可高的全局系統 CPU 利用率 ;內存不夠出錯 (out of memory errors)處理器：1 UNIX 資源監控( Windows 操作系統同理)中指標 CPU 占用率( CPU utilizatio

27、n )，如果該值持續超過95%，表明瓶頸是 CPU。可以考慮增加一個處理器或換一個更快的處理器。如果服務器專用于 SQL Server,可接受的最大上限是 80-85%合理使用的范圍在 60%至 70%。2 Windows 資源監控中，如果 SystemProcessor Queue Length 大于 2，而處理器利用率(Processor Time)直很低，則存在著處理器阻塞。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)磁盤 I/O ：1 UNIX 資源監控( Windows 操作系統同理)中指標磁盤交換率( Disk rate) ，如果該參數值 一直很高，表明 I/O 有問題。可考慮更換更快的硬盤系統。2 Windows 資源監控中，如果 Disk Tim