MILY: 宋體; mso-ascii-font-family: " Times Roman?; mso-hansi-font-family: ?Times New Roman??>軟件性能測試（并發負載壓力）測試分析
分析原則：
• 具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）
• 查找瓶頸時按以下順序，由易到難。
注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
• 分段排除法 很有效
分析的信息來源：
1 根據場景運行過程中的錯誤提示信息
2 根據測試結果收集到的監控指標數據
一．錯誤提示分析
分析實例：
1 • Error: Failed to connect to server “ 10.10.10 .30:8080 ″ : [10060] Connection
• Error: timed out Error: Server “ 10.10.10 .30 ″ has shut down the connection prematurely
分析：
• A 、應用服務死掉。
（小用戶時：程序上的問題。程序上處理數據庫的問題）
• B 、應用服務沒有死
（應用服務參數設置問題）
例：在許多客戶端連接 Weblogic 應用服務器被拒絕，而在服務器端沒有錯誤顯示，則有可能是 Weblogic 中的 server 元素的 AcceptBacklog 屬性值設得過低。如果連接時收到 connection refused 消息，說明應提高該值，每次增加 25 ％
• C 、數據庫的連接
(1 、在應用服務的性能參數可能太小了 2 、數據庫啟動的最大連接數（跟硬件的內存有關） )
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
B 、頁面中圖片太多
C 、在程序處理表的時候檢查字段太大多
二．監控指標數據分析
1 ．最大并發用戶數：
應用系統在當前環境（硬件環境、網絡環境、軟件環境（參數配置））下能承受的最大并發用戶數。
-
在方案運行中，如果出現了大于 3 個用戶的業務操作失敗，或出現了服務器 shutdown 的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓力，那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數。
-
如果測得的最大并發用戶數到達了性能要求，且各服務器資源情況良好，業務操作響應時間也達到了用戶要求，那么 OK 。否則，再根據各服務器的資源情況和業務操作響應時間進一步分析原因所在。
2 ．業務操作響應時間：
• 分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用“事務性能摘要”圖，可以確定在方案執行期間響應時間過長的事務。
• 細分事務并分析每個頁面組件的性能。查看過長的事務響應時間是由哪些頁面組件引起的？問題是否與網絡或服務器有關？
• 如果服務器耗時過長，請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能下降的原因。如果網絡耗時過長，請使用“網絡監視器”圖確定導致性能瓶頸的網絡問題
3 ．服務器資源監控指標：
內存：
2 Windows 資源監控中，如果 Process\Private Bytes 計數器和 Process\Working Set 計數器的值在長時間內持續升高，同時 Memory\Available bytes 計數器的值持續降低，則很可能存在內存泄漏。
內存資源成為系統性能的瓶頸的征兆 :
-
很高的換頁率 (high pageout rate);
-
進程進入不活動狀態 ;
-
交換區所有磁盤的活動次數可高 ;
-
可高的全局系統 CPU 利用率 ;
-
內存不夠出錯 (out of memory errors)
處理器：
1 UNIX 資源監控（ Windows 操作系統同理）中指標 CPU 占用率（ CPU utilization ），如果該值持續超過 95% ，表明瓶頸是 CPU �？梢钥紤]增加一個處理器或換一個更快的處理器。如果服務器專用于 SQL Server, 可接受的最大上限是 80-85%
合理使用的范圍在 60% 至 70% 。
2 Windows 資源監控中，如果 System\Processor 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 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)
-
過低的緩存命中率 (low buffer cache hit ratio(not sufficient in itself))
-
太長的運行進程隊列，但 CPU 卻空閑 (large run queue with idle CPU)
4 ．數據庫服務器：
SQL Server 數據庫：
2 如果 Full Scans/sec （全表掃描 / 秒）計數器顯示的值比 1 或 2 高，則應分析你的查詢以確定是否確實需要全表掃描，以及 SQL 查詢是否可以被優化。
3 Number of Deadlocks/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) from 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 + 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$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’
注：上述 SQL Server 和 Oracle 數據庫分析，只是一些簡單、基本的分析，特別是 Oracle 數據庫的分析和優化，是一門專門的技術，進一步的分析可查相關資料。
延伸閱讀
文章來源于領測軟件測試網 http://www.k11sc111.com/
