性能測試瓶頸分析

1、性能測試瓶頸分析來源:未知 作者:領(lǐng)測軟件測試網(wǎng)采編 發(fā)表時間 :2011-07-06 09:45點 擊 :512次 軟件測試工具電信測試游戲測試安全測試本地化測試手機測試 Web 測試其它相關(guān) 軟件測試工程師入門軟件測試外包測試模板金融測試嵌入式測試云測試軟件測試工程師職 業(yè)發(fā)展單元測試功能測試測試用例性能測試自動測試測試管理缺陷管理測試認證敏捷測試 同一場景 1. 小用戶量的情況下測試 2. 大用戶量情況下的測試 分析的方法:整個系統(tǒng)架構(gòu) 分析,系統(tǒng)響應(yīng)時間消耗,利用圖表分析 查看事務(wù)響應(yīng)時間,通過事務(wù)摘要圖分析事務(wù)響 應(yīng)時間,那個消耗最大 (通過小用戶量和大用戶量 同一場景1. 小用戶量

2、的情況下測試2. 大用戶量情況下的測試分析的方法:整個系統(tǒng)架構(gòu)分析,系統(tǒng)響應(yīng)時間消耗,利用圖表分析查看事務(wù)響應(yīng)時間,通過事務(wù)摘要圖分析事務(wù)響應(yīng)時間,那個消耗最大 (通過小用戶量 和大用戶量的響應(yīng)時間分析, 查看那個事務(wù)響應(yīng)時間最高 , 確定哪部分功能是性能的瓶頸, 分析 window resource圖表,查看 cpu使用下列計數(shù)器標識 cpu 瓶頸Processor Interrupts/secProcessor % Processor TimeProcess(process % Processor TimeSystem Processor Queue Length通過它來確定是否硬件本身出

3、現(xiàn)瓶頸, 或者進一步確定應(yīng)該怎么去判斷性能產(chǎn)生瓶頸的地方 !下一步去判斷進程,那個進程消耗 cpu 最高下邊就有很多種情況需要你自己去判斷, 有可能是進程調(diào)用了的函數(shù)消耗了系統(tǒng)資源形 成上邊的問題,也有可能是后臺數(shù)據(jù)庫出現(xiàn)的問題 (這個就要看你的系統(tǒng)配置是什么樣的, 比如你的 db 服務(wù)器和應(yīng)用服務(wù)器都配置在一臺機器上 性能產(chǎn)生瓶頸有很多地方,所以需要進一判斷,是否是后臺數(shù)據(jù)庫的問題還有待分析, 是那條語句導(dǎo)致的問題需要進一步分析判斷。分析原則:? 具體問題具體分析 (這是由于不同的應(yīng)用系統(tǒng),不同的測試目的,不同的性能關(guān)注點 ? 查找瓶頸時按以下順序,由易到難。服務(wù)器硬件瓶頸 - 網(wǎng)絡(luò)瓶頸 (

4、對局域網(wǎng), 可以不考慮 - 服務(wù)器操作系統(tǒng)瓶頸 (參數(shù)配置 - 中間件瓶頸 (參數(shù)配置,數(shù)據(jù)庫, web 服務(wù)器等 -應(yīng)用瓶頸 (SQL語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù) 邏輯、算法等 注:以上過程并不是每個分析中都需要的,要根據(jù)測試目的和要求來確定分析的深度。 對一些要求低的,我們分析到應(yīng)用系統(tǒng)在將來大的負載壓力 (并發(fā)用戶數(shù)、數(shù)據(jù)量 下,系統(tǒng) 的硬件瓶頸在哪兒就夠了。? 分段排除法 很有效分析的信息來源:?1 根據(jù)場景運行過程中的錯誤提示信息?2 根據(jù)測試結(jié)果收集到的監(jiān)控指標數(shù)據(jù)一 . 錯誤提示分析分析實例:?A 、應(yīng)用服務(wù)死掉。(小用戶時:程序上的問題。程序上處理數(shù)據(jù)庫的問題 ?B 、應(yīng)用服務(wù)沒有死

5、(應(yīng)用服務(wù)參數(shù)設(shè)置問題 例:在許多客戶端連接 Weblogic 應(yīng)用服務(wù)器被拒絕,而在服務(wù)器端沒有錯誤顯示,則 有可能是 Weblogic 中的 server 元素的 Aclearcase/" target="_blank" >cceptBacklog屬性值設(shè)得 過低。如果連接時收到 connection refused消息,說明應(yīng)提高該值,每次增加 25%?C 、數(shù)據(jù)庫的連接(1、在應(yīng)用服務(wù)的性能參數(shù)可能太小了 2、數(shù)據(jù)庫啟動的最大連接數(shù) (跟硬件的內(nèi)存有 關(guān) 2 Error: Page download timeout (120 seconds has

6、expired分析:可能是以下原因造成?A 、應(yīng)用服務(wù)參數(shù)設(shè)置太大導(dǎo)致服務(wù)器的瓶頸?B 、頁面中圖片太多?C 、在程序處理表的時候檢查字段太大多二 . 監(jiān)控指標數(shù)據(jù)分析1. 最大并發(fā)用戶數(shù):應(yīng)用系統(tǒng)在當前環(huán)境 (硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、軟件環(huán)境 (參數(shù)配置 下能承受的最大并發(fā) 用戶數(shù)。在方案運行中,如果出現(xiàn)了大于 3個用戶的業(yè)務(wù)操作失敗,或出現(xiàn)了服務(wù)器 shutestdirector/" target="_blank" >tdown的情況,則說明在當前環(huán)境下,系統(tǒng)承受不了當前并 發(fā)用戶的負載壓力,那么最大并發(fā)用戶數(shù)就是前一個沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。如果測得

7、的最大并發(fā)用戶數(shù)到達了性能要求, 且各服務(wù)器資源情況良好, 業(yè)務(wù)操作響應(yīng) 時間也達到了用戶要求,那么 OK 。否則,再根據(jù)各服務(wù)器的資源情況和業(yè)務(wù)操作響應(yīng)時間 進一步分析原因所在。2. 業(yè)務(wù)操作響應(yīng)時間:? 分析方案運行情況應(yīng)從平均事務(wù)響應(yīng)時間圖和事務(wù)性能摘要圖開始。 使用 “事務(wù)性能 摘要”圖,可以確定在方案執(zhí)行期間響應(yīng)時間過長的事務(wù)。? 細分事務(wù)并分析每個頁面組件的性能。 查看過長的事務(wù)響應(yīng)時間是由哪些頁面組件引 起的 ? 問題是否與網(wǎng)絡(luò)或服務(wù)器有關(guān) ? 如果服務(wù)器耗時過長, 請使用相應(yīng)的服務(wù)器圖確定有問題的服務(wù)器度量并查明服務(wù)器 性能下降的原因。如果網(wǎng)絡(luò)耗時過長,請使用 “網(wǎng)絡(luò)監(jiān)視器”

8、圖確定導(dǎo)致性能瓶頸的網(wǎng)絡(luò)問 題3. 服務(wù)器資源監(jiān)控指標:內(nèi)存:1 UNIX資源監(jiān)控中指標內(nèi)存頁交換速率 (Paging rate,如果該值偶爾走高,表明當時有 線程競爭內(nèi)存。如果持續(xù)很高,則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低。2Windows 資源監(jiān)控中,如果 ProcessPrivate Bytes計數(shù)器和 ProcessWorking Set計數(shù)器 的值在長時間內(nèi)持續(xù)升高,同時 MemoryAvailable bytes 計數(shù)器的值持續(xù)降低,則很可能存 在內(nèi)存泄漏。內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆 :很高的換頁率 (high pageout rate;進程進入不活動狀態(tài) ;交換區(qū)所有

9、磁盤的活動次數(shù)可高 ;可高的全局系統(tǒng) CPU 利用率 ;內(nèi)存不夠出錯 (out of memory errors處理器:1 UNIX資源監(jiān)控 (Windows操作系統(tǒng)同理 中指標 CPU 占用率 (CPU utilization,如果該 值持續(xù)超過 95%,表明瓶頸是 CPU 。可以考慮增加一個處理器或換一個更快的處理器。如 果服務(wù)器專用于 SQL Server,可接受的最大上限是 80-85%合理使用的范圍在 60%至 70%。 2 Windows 資源監(jiān)控中，如果 SystemProcessor Queue Length 大于 2，而處理器利用率 (Processor Time一直很低，則

10、存在著處理器阻塞。 CPU 資源成為系統(tǒng)性能的瓶頸的征兆: 很慢的響應(yīng)時間(slow response time 性能測試瓶頸分析(2來源：未知 作者：領(lǐng)測軟件測試網(wǎng)采編 發(fā)表時間:2011-07-06 09:45 點擊:513 次 軟件測試工具電信測試游戲測試安全測試本地化測試手機測試 Web 測試其它相 關(guān)軟件測試工程師入門軟件測試外包測試模板金融測試嵌入式測試云測試軟件測試工程師 職業(yè)發(fā)展單元測試功能測試測試用例性能測試自動測試測試管理缺陷管理測試認證敏捷測 試 CPU 空閑時間為零(zero percent idle CPU 過高的用戶占用 CPU 時間(high percent us

11、er CPU 過高的系統(tǒng)占用 CPU 時間(high percent system CPU 長時間的有很長的運行進程隊列 (large run queue size sustained over tim CPU 空閑時間為零(zero percent idle CPU 過高的用戶占用 CPU 時間(high percent user CPU 過高的系統(tǒng)占用 CPU 時間(high percent system CPU 長時間的有很長的運行進程隊列(large run queue size sustained over time 磁盤 I/O： 1 UNIX 資源監(jiān)控(Windows 操作系統(tǒng)同

12、理中指標磁盤交換率(Disk rate，如果該參數(shù)值 一直很高，表明 I/O 有問題?？煽紤]更換更快的硬盤系統(tǒng)。 2 Windows 資源監(jiān)控中，如果 Disk Time 和 Avg.Disk Queue Length 的值很高，而 Page Reads/sec 頁面讀取操作速率很低，則可能存在磁盤瓶徑。 I/O 資源成為系統(tǒng)性能的瓶頸的征兆 : 過高的磁盤利用率(high disk utilization 太長的磁盤等待隊列(large disk queue length 等待磁盤 I/O 的時間所占的百分率太高(large percentage of time waiting for di

13、sk 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.數(shù)據(jù)庫服務(wù)器： SQL Server 數(shù)據(jù)庫： 1 SQLServer 資源監(jiān)控中指標緩存點擊率(Cache Hit Ratio，該值越高越好。如果持續(xù)低 于 80%，應(yīng)考慮增加內(nèi)存。 2 如果 Full Scans/sec(全表掃描/

14、秒計數(shù)器顯示的值比 1 或 2 高， 則應(yīng)分析你的查詢以確 定是否確實需要全表掃描，以及 SQL 查詢是否可以被優(yōu)化。 3 Number of Deadlocks/sec(死鎖的數(shù)量/秒：死鎖對應(yīng)用程序的可伸縮性非常有害，并 且會導(dǎo)致惡劣的用戶體驗。該計數(shù)器的值必須為 0。 4 Lock Requests/sec(鎖請求/秒，通過優(yōu)化查詢來減少讀取次數(shù)，可以減少該計數(shù)器的 值。 Oracle 數(shù)據(jù)庫： 1 如果自由內(nèi)存接近于 0 而且?guī)炜齑婊驍?shù)據(jù)字典快存的命中率小于 0.90， 那么需要增加 SHARED_POOL_SIZE 的大小。 快存(共享 SQL 區(qū)和數(shù)據(jù)字典快存的命中率： selec

15、t(sum(pins-reloads/sum(pins from v$librarycache; select(sum(gets-getmisses/sum(gets from v$rowcache; 自由內(nèi)存： select * from v$sgastat where name=free memory; 2 如果數(shù)據(jù)的緩存命中率小于 0.90， 那么需要加大 DB_BLOCK_BUFFERS 參數(shù)的值(單 位：塊。 緩沖區(qū)高速緩存命中率： 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 如果日志緩沖區(qū)申請的值較大，則應(yīng)加大 LOG_BUFFER 參數(shù)的值。 日志緩沖區(qū)的申請情況 ： select name,value from v$sysstat where name = 'redo log space