性能測試是通過(guò)自動(dòng)化的測試工具模擬多種正常、峰值以及異常負載條件來(lái)對系統的各項性能指標進(jìn)行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進(jìn)行。通過(guò)負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時(shí)，系統各項性能指標的變化情況。壓力測試是通過(guò)確定一個(gè)系統的瓶頸或者不能接收的性能點(diǎn)，來(lái)獲得系統能提供的最大服務(wù)級別的測試。
分析原則：
• 具體問(wèn)題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關(guān)注點(diǎn)）
• 查找瓶頸時(shí)按以下順序，由易到難。
服務(wù)器硬件瓶頸-〉網(wǎng)絡(luò )瓶頸（對局域網(wǎng)，可以不考慮）-〉服務(wù)器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務(wù)器等）-〉應用瓶頸（SQL語(yǔ)句、數據庫設計、業(yè)務(wù)邏輯、算法等）
注：以上過(guò)程并不是每個(gè)分析中都需要的，要根據測試目的和要求來(lái)確定分析的深度。對一些要求低的，我們分析到應用系統在將來(lái)大的負載壓力（并發(fā)用戶(hù)數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
• 分段排除法 很有效
分析的信息來(lái)源：
•1 根據場(chǎng)景運行過(guò)程中的錯誤提示信息
•2 根據測試結果收集到的監控指標數據
一．錯誤提示分析
分析實(shí)例：
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、應用服務(wù)死掉。
（小用戶(hù)時(shí)：程序上的問(wèn)題。程序上處理數據庫的問(wèn)題）
•B、應用服務(wù)沒(méi)有死
（應用服務(wù)參數設置問(wèn)題）
例：在許多客戶(hù)端連接Weblogic應用服務(wù)器被拒絕，而在服務(wù)器端沒(méi)有錯誤顯示，則有可能是Weblogic中的server元素的AcceptBacklog屬性值設得過(guò)低。如果連接時(shí)收到connection refused消息，說(shuō)明應提高該值，每次增加25％
•C、數據庫的連接
(1、在應用服務(wù)的性能參數可能太小了 2、數據庫啟動(dòng)的最大連接數（跟硬件的內存有關(guān)）)
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
•A、應用服務(wù)參數設置太大導致服務(wù)器的瓶頸
•B、頁(yè)面中圖片太多
•C、在程序處理表的時(shí)候檢查字段太大多
二．監控指標數據分析
1．最大并發(fā)用戶(hù)數：
應用系統在當前環(huán)境（硬件環(huán)境、網(wǎng)絡(luò )環(huán)境、軟件環(huán)境（參數配置））下能承受的最大并發(fā)用戶(hù)數。
在方案運行中，如果出現了大于3個(gè)用戶(hù)的業(yè)務(wù)操作失敗，或出現了服務(wù)器shutdown的情況，則說(shuō)明在當前環(huán)境下，系統承受不了當前并發(fā)用戶(hù)的負載壓力，那么最大并發(fā)用戶(hù)數就是前一個(gè)沒(méi)有出現這種現象的并發(fā)用戶(hù)數。
如果測得的最大并發(fā)用戶(hù)數到達了性能要求，且各服務(wù)器資源情況良好，業(yè)務(wù)操作響應時(shí)間也達到了用戶(hù)要求，那么OK。否則，再根據各服務(wù)器的資源情況和業(yè)務(wù)操作響應時(shí)間進(jìn)一步分析原因所在。
2．業(yè)務(wù)操作響應時(shí)間：
• 分析方案運行情況應從平均事務(wù)響應時(shí)間圖和事務(wù)性能摘要圖開(kāi)始。使用“事務(wù)性能摘要”圖，可以確定在方案執行期間響應時(shí)間過(guò)長(cháng)的事務(wù)。
• 細分事務(wù)并分析每個(gè)頁(yè)面組件的性能。查看過(guò)長(cháng)的事務(wù)響應時(shí)間是由哪些頁(yè)面組件引起的？問(wèn)題是否與網(wǎng)絡(luò )或服務(wù)器有關(guān)？
• 如果服務(wù)器耗時(shí)過(guò)長(cháng)，請使用相應的服務(wù)器圖確定有問(wèn)題的服務(wù)器度量并查明服務(wù)器性能下降的原因。如果網(wǎng)絡(luò )耗時(shí)過(guò)長(cháng)，請使用“網(wǎng)絡(luò )監視器”圖確定導致性能瓶頸的網(wǎng)絡(luò )問(wèn)題
3．服務(wù)器資源監控指標：
內存：
1 UNIX資源監控中指標內存頁(yè)交換速率（Paging rate），如果該值偶爾走高，表明當時(shí)有線(xiàn)程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪(fǎng)問(wèn)命中率低。
2 Windows資源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長(cháng)時(shí)間內持續升高，同時(shí)Memory\Available bytes計數器的值持續降低，則很可能存在內存泄漏。
內存資源成為系統性能的瓶頸的征兆:
很高的換頁(yè)率(high pageout rate);
進(jìn)程進(jìn)入不活動(dòng)狀態(tài);
交換區所有磁盤(pán)的活動(dòng)次數可高;
可高的全局系統CPU利用率;
內存不夠出錯(out of memory errors)
處理器：
1 UNIX資源監控（Windows操作系統同理）中指標CPU占用率（CPU utilization），如果該值持續超過(guò)95%，表明瓶頸是CPU�？梢钥紤]增加一個(gè)處理器或換一個(gè)更快的處理器。如果服務(wù)器專(zhuān)用于SQL Server,可接受的最大上限是80-85%
合理使用的范圍在60%至70%。
2 Windows資源監控中，如果System\Processor Queue Length大于2，而處理器利用率（Processor Time）一直很低，則存在著(zhù)處理器阻塞。
CPU資源成為系統性能的瓶頸的征兆:
很慢的響應時(shí)間(slow response time)
CPU空閑時(shí)間為零(zero percent idle CPU)
過(guò)高的用戶(hù)占用CPU時(shí)間(high percent user CPU)
過(guò)高的系統占用CPU時(shí)間(high percent system CPU)
長(cháng)時(shí)間的有很長(cháng)的運行進(jìn)程隊列(large run queue size sustained over time)
磁盤(pán)I/O：
1 UNIX資源監控（Windows操作系統同理）中指標磁盤(pán)交換率（Disk rate），如果該參數值一直很高，表明I/O有問(wèn)題�？煽紤]更換更快的硬盤(pán)系統。
2 Windows資源監控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁(yè)面讀取操作速率很低，則可能存在磁盤(pán)瓶徑。
I/O資源成為系統性能的瓶頸的征兆 :
過(guò)高的磁盤(pán)利用率(high disk utilization)
太長(cháng)的磁盤(pán)等待隊列(large disk queue length)
等待磁盤(pán)I/O的時(shí)間所占的百分率太高(large percentage of time waiting for disk I/O)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
過(guò)低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))
太長(cháng)的運行進(jìn)程隊列，但CPU卻空閑(large run queue with idle CPU)
4．數據庫服務(wù)器：
SQL Server數據庫：
1 SQLServer資源監控中指標緩存點(diǎn)擊率（Cache Hit Ratio），該值越高越好。如果持續低于80%，應考慮增加內存。
2 如果Full Scans/sec（全表掃描/秒）計數器顯示的值比1或2高，則應分析你的查詢(xún)以確定是否確實(shí)需要全表掃描，以及SQL查詢(xún)是否可以被優(yōu)化。
3 Number of Deadlocks/sec(死鎖的數量/秒)：死鎖對應用程序的可伸縮性非常有害，并且會(huì )導致惡劣的用戶(hù)體驗。該計數器的值必須為0。
4 Lock Requests/sec(鎖請求/秒)，通過(guò)優(yōu)化查詢(xún)來(lái)減少讀取次數，可以減少該計數器的值。
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以避免磁盤(pán)排序 。
內存排序命中率 ：
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)'
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
