評論(0

負載壓力測試

標籤: 暫無標籤

負載壓力測試是在一定約束條件下測試系統所能承受的併發用戶量、運行時間、數據量,以確定系統所能承受的最大負載壓力。

1 負載壓力測試 -基本概述

負載壓力測試負載壓力測試中動態參數關聯
負載壓力測試有助於確認被測系統是否能夠支持性能需求,以及預期的負載增長等。負載壓力測試不只是關注不同負載場景下的響應時間等指標,它也要通過測試來發現在不同負載場景下會出現的,例如速度變慢、內存泄漏等問題的原因。負載壓力測試是性能測試的重要組成部分,負載壓力測試包括併發性能測試、疲勞強度測試、大數據量測試等內容。一般包括如下:

1、性能測試

性能測試用來保證產品發布后系統的性能能夠滿足用戶需求。其中系統性能包括執行效率、資源佔用、穩定性、安全性、兼容性、可擴展性、可靠性等。

2、性能評測

負載壓力測試負載壓力測試結構剖析

性能評測包括:在真實環境下,檢查系統服務等級的滿足情況,評估並報告整個系統的性能;對系統的未來容量作出預測和規劃。

3、性能調優

性能調優一般的步驟為首先查找形成系統瓶頸或者故障的根本原因,其次是進行性能調整和優化,最後便是評估性能調整的結果。

4、負載測試

負載測試時通過逐步增加系統負載,測試系統性能的變化,並最終確定在滿足性能指標的情況下,系統所能承受的最大負載量的測試。


負載壓力測試負載壓力測試工具
5、壓力測試

壓力測試是通過逐步增加系統負載,測試系統性能的變化,並最終確定在什麼負載條件下系統性能處於失效狀態,並以此來獲得系統能提供的最大服務級別的測試。

6、併發性測試

併發性測試的過程,是一個負載測試和壓力測試的過程。即逐漸增加併發用戶數負載,直到系統的瓶頸或者不能接收的性能點。併發性測試分為三類:

a、應用在客戶端性能的測試;
b、應用在網路上性能的測試;
c、應用在伺服器上性能的測試;

7、疲勞強度測試

8、大數據量測試

大數據量測試包括獨立的數據量測試和綜合數據量測試兩類。

2 負載壓力測試 -負載測試

負載壓力測試伺服器負載測試
術語「負載測試」在測試文獻資料中通常都被定義為給被測系統加上它所能操作的最大任務數的過程。負載測試有時也會被稱為「容量測試」,或者「耐久性測試/持久性測試」。

容量測試的例子:
通過編輯一個巨大的文件來測試文字處理軟體;
通過發送一個巨大的作業來測試印表機;
通過成千上萬的用戶郵箱來測試郵件伺服器;
有一種比較特別的容量測試是叫作「零容量測試」,它是給系統加上空任務來測試的。

耐久性測試/持久性測試的的例子:在一個循環中不停的運行客戶端超過一個擴展時間段。

負載測試的目的:
找到一些在測試流程中前面的階段所進行的粗略測試中沒有被找出的bugs,例如,內存管理bugs,內存泄露,緩衝器溢出等等。保證應用程序達到性能測試中確定的性能基線。這個可以在運行回歸試驗時,通過載入特定的最大限度的負載來實現。儘管性能測試和負載測試似乎很像,但他們的目的還是有差異的。一方面,性能測試使用負載測試的技術,工具,以及用不同的負載程度來測度和基準化系統。在另一方面來講,負載測試是在一些已經定義好的負載程度上進行測試的,通常對系統加上最大負載之後,系統應該仍然可以提供全部功能。這裡需要明確一點,負載測試並不是要對系統載入上過度的負載而使系統不能工作,而是要使系統像一個上滿了油的機器嗡嗡叫。

在負載測試的相關內容中,我想應該非常重要的是要有十分充足的數據來進行測試。從我的經驗中得知,假若不用非常大的數據*去測的話,有很多嚴重的bug是不會的到的。比如說,LDAP/NIS/ActiveDirectory資料庫中成千上萬的用戶,郵件伺服器中成千上萬的郵箱,資料庫中成G成G的表,文件系統中很深的文件或者目錄的層次,等等。顯然,測試人員就需要使用自動化工具來產生這些龐大的數據集,比較幸運的是任何優秀的腳本語言都可以勝任這些工作。

3 負載壓力測試 -壓力測試

負載壓力測試負載壓力測試站點測試工具
壓力測試是指通過對系統載入過度的資源或者例系統沒有應該具有的令系統可以正常運作的資源,來使系統崩潰(在某些情況的時候,它又可以叫做負面測試)。進行這個瘋狂行為的主要目的是為了保證系統出故障及可以適當的恢復,而這個恢復得怎麼樣的特性則是叫做可恢復性。

當性能測試需要的是一個可控制的環境和不斷的測度的時候,壓力測試則是令為歡喜的引起混亂及不可預測性(譯者按:從這一點可以看出作者是一個很優秀的測試人員)。還是舉WEB應用系統為例,下面是一些對系統可行的壓力測試方法:兩倍的已經基線的併發用戶數或者HTTP連接數;隨機的關閉及重開連接到伺服器上的網路上集線器/路由器的埠(例如,可以通過SNMP命令來實現);把資料庫斷線然後再重啟;當系統還在運行的時候,重建一個RAID陣列;在WEB和資料庫伺服器上運行消耗資源(如CPU,內存,磁碟,網路)的進程。

4 負載壓力測試 -性能測試

負載壓力測試負載壓力測試
性能測試的目的不是去找bugs,而是排除系統的瓶頸,以及為以後的回歸測試建立一個基準。而性能測試的操作,實際上就是一個非常小心受控的測量分析過程。在理想的情況下,被測軟體在這個時候已經是足夠穩定了,所以這個過程得以順利的進行。一組清晰已定義好的預期值是讓一次有意義的性能測試的基本要素。如果連你自己都不知道系統性能有些什麼是要測的,那麼它對於你要測試的方法手段是沒有指導意義的*。例如,給一個web應用做性能測試,你要知道至少兩樣東西:在不同併發用戶數或者HTTP連接數情況下的負載預期值;可接受的響應時間;當你知道你的目標后,你就可以開始使用對系統持續增加負載的方法來觀察系統的瓶頸所在。重新拿web應用系統來做例子,這些瓶頸可存在於多個層次,你可以使用多種工具來查明它們的所在:在應用層,開發人員可以通過profilers來發現低效率的代碼,比如說較差的查找演算法;在資料庫層,開發人員和資料庫管理員(DBA)可以通過特定的資料庫profilers及事件探查器(queryoptimizers)。

在操作系統層,系統工程師可以使用一些工具如在Unix類的操作系統中的top、vmstat、iostat、在Windows系統中的PerfMon來監控CPU,內在,swap、磁碟I/O等硬體資源;專門的內核監控軟體也可以在這一層面上被使用。在網路層上,網路工程師可以使用報文探測器(如tcpdump)。網路協議分析器(如ethereal),還有其它的工具(如netstat、MRTG、NTOP、mii-tool)

從測試的觀點來看,上面所有描述的活動都是一種白盒的方法,它對系統從內到外及多角度進行審查及監控。測度數據被取得及分析后,對系統的調整則成為理所當然的下一個步驟。然而,(除了上面的方法外)測試人員在給被測系統運行負載試驗(這裡為了不與我們所理解的負載測試-loadtesting的概念搞混,特譯做負載試驗)的時候,也採取了黑盒的方法。像對於WEB應用來講,測試人員可以使用工具來模擬併發用戶或者HTTP連接及測量響應時間。在我以前使用過的輕量級的負載測試開源工具有ab、siege、httperf。一個更重量級的工具是OpenSTA,但我沒用過。我也還沒有用過TheGrinder這個工具,但它在我將要做的事情中排名靠前。

當負載試驗的結果顯示出系統的性能來沒有達到它的預期目標時,這就是要對應用和資料庫的調整的時候了。同時你要確保讓你的代碼運行得儘可能高效,以及資料庫在給定的操作系統和硬體配置的情況下最優化。測試驅動開發(TDD)的實踐者會發現這種上下文結構框架是非常有用的,如可以通過負載試驗及時間試驗的函數性來增強現存單元測試代碼的MikeClark的junitperf。當一個特定的函數或者方法被剖析過和調試過後,開發人員就可以在jUnitPerf中,放入它的單元試驗來確保它可以達到負載及時間上的性能需求。MikeClark稱這為「持續性能測試」。我順便也提一下我已經做了一個基於Python的jUnitPerf的初步研究,我稱之為pyUnitPerf。

假若在調試過應用程序及資料庫后,系統還是沒有達到性能的預期目標,在這種情況下,還是有一些其它的調試的流程可以針對前面講過的那幾個層次來使用的。下面就是一些在應用程序代碼*之外仍可以提高WEB應用系統性

負載壓力測試負載壓力測試模擬網路連接環境
能的例子:
使用WEB緩存裝制,如Squid提供的裝置;
將高訪問量的網頁靜態化,以避免這些高訪問量對資料庫進行大量的調用;
通過負載平衡的方法來水平縮放WEB伺服器的結構;
在水平縮放資料庫群及將它們分為讀寫伺服器和只讀伺服器后,還要對只讀伺服器群負載平衡;
通過增加更多的硬體資源(CPU,內存,磁碟等)縱向的縮放WEB及資料庫伺服器群;
增加網路的帶寬。

由於現在的WEB應用系統都是十分複雜的系統,性能調試有時要具有一些藝術性才行。在每次修改一個變數及重新測度的時候一定要非常小心,否則的話,在變化中將會有很多難於確定和重複的不確定因素。在一個規範的測試環境比如說一個測試實驗試,它是不會常常的重現實際應用時的伺服器配置環境。在這樣的情況下,分段測試環境,也就是生產實際環境的一個子集就可以派上用場了。但同時系統的期望性能也需要相應的調低一點。「運行負載試驗->測度性能->調試系統」這個循環一直要被重複執行到被測試系統達到了期望的性能標準了才可以停。在這個時候,測試人員就可以明了在正常條件下的系統運轉怎麼樣,同時這些就可以做為以後在回歸測試中,評價新版本的軟體性能的一個標準了。性能測試還有另一個目標就是建立一組被測系統的基準數據。在很多行業中都會有這種行業標準的基準數據,比如說TPC公布的。還有很多軟硬體廠家都為了在TCP排名中靠前而對他們的機器進行精心調試。所以說你應當非常謹慎的說明在你進行測試的時候,並沒有在種類繁多的軟硬體產品中進行全部測試。

5 負載壓力測試 -分析處理

分析原則:

1、具體問題具體分析(這是由於不同的應用系統,不同的測試目的,不同的性能關注點)
2、查找瓶頸時按以下順序,由易到難。

伺服器硬體瓶頸-〉網路瓶頸(對區域網,可以不考慮)-〉伺服器操作系統瓶頸(參數配置)-〉中間件瓶頸(參數配置,資料庫,web伺服器等)-〉應用瓶頸(SQL語句、資料庫設計、業務邏輯、演算法等)註:以上過程並不是每個分析中都需要的,要根據測試目的和要求來確定分析的深度。對一些要求低的,我們分析到應用系統在將來大的負載壓力(併發用戶數、數據量)下,系統的硬體瓶頸在哪兒就夠了。分段排除法很有效。

負載壓力測試負載壓力測試
分析的信息來源:

1、根據場景運行過程中的錯誤提示信息;
2、根據測試結果收集到的監控指標數據。

一、錯誤提示分析

分析實例:

1、Error:Failedtoconnecttoserver「10.10.10.30:8080″:[10060]Connection

     Error:timedoutError:Server「10.10.10.30″hasshutdowntheconnectionprematurely

分析:

A、應用服務死掉(小用戶時:程序上的問題。程序上處理資料庫的問題)

B、應用服務沒有死(應用服務參數設置問題)

例:在許多客戶端連接Weblogic應用伺服器被拒絕,而在伺服器端沒有錯誤顯示,則有可能是Weblogic中的server元素的AcceptBacklog屬性值設得過低。如果連接時收到connectionrefused消息,說明應提高該值,每次增加25%

C、資料庫的連接(1、在應用服務的性能參數可能太小了;2、資料庫啟動的最大連接數(跟硬體的內存有關)。)

分析:可能是以下原因造成

A、應用服務參數設置太大導致伺服器的瓶頸;B、頁面中圖片太多;C、在程序處理表的時候檢查欄位太大多。

二.監控指標數據分析

1、最大併發用戶數:

應用系統在當前環境(硬體環境、網路環境、軟體環境(參數配置))下能承受的最大併發用戶數。在方案運行中,如果出現了大於3個用戶的業務操作失敗,或出現了伺服器shutdown的情況,則說明在當前環境下,系統承受不了當前併發用戶的負載壓力,那麼最大併發用戶數就是前一個沒有出現這種現象的併發用戶數。如果測得的最大併發用戶數到達了性能要求,且各伺服器資源情況良好,業務操作響應時間也達到了用戶要求,那麼可行。否則,再根據各伺服器的資源情況和業務操作響應時間進一步分析原因所在。

2、業務操作響應時間:

分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用「事務性能摘要」圖,可以確定在方案執行期間響應時間過長的事務。細分事務並分析每個頁面組件的性能。如果伺服器耗時過長,請使用相應的伺服器圖確定有問題的伺服器度量並查明伺服器性能下降的原因。如果網路耗時過長,請使用「網路監視器」圖確定導致性能瓶頸的網路問題

負載壓力測試負載壓力測試
3、伺服器資源監控指標:

內存:

1、UNIX資源監控中指標內存頁交換速率(Pagingrate),如果該值偶爾走高,表明當時有線程競爭內存。如果持續很高,則內存可能是瓶頸。也可能是內存訪問命中率低。

2、Windows資源監控中,如果Process\PrivateBytes計數器和Process\WorkingSet計數器的值在長時間內持續升高,同時Memory\Availablebytes計數器的值持續降低,則很可能存在內存泄漏。

內存資源成為系統性能的瓶頸的徵兆:很高的換頁率(highpageoutrate);進程進入不活動狀態;交換區所有磁碟的活動次數可高;可高的全局系統CPU利用率;內存不夠出錯(outofmemoryerrors)。

處理器:

1、UNIX資源監控(Windows操作系統同理)中指標CPU佔用率(CPUutilization),如果該值持續超過95%,表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。如果伺服器專用於SQLServer,可接受的最大上限是80-85%合理使用的範圍在60%至70%。

2、Windows資源監控中,如果System\ProcessorQueueLength大於2,而處理器利用率(ProcessorTime)一直很低,則存在著處理器阻塞。

CPU資源成為系統性能的瓶頸的徵兆:很慢的響應時間(slowresponsetime);CPU空閑時間為零(zeropercentidleCPU);過高的用戶佔用CPU時間(highpercentuserCPU);過高的系統佔用CPU時間(highpercentsystemCPU);長時間的有很長的運行進程隊列(largerunqueuesizesustainedovertime)。

磁碟I/O:

1、UNIX資源監控(Windows操作系統同理)中指標磁碟交換率(Diskrate),如果該參數值一直很高,表明I/O有問題。可考慮更換更快的硬碟系統。

2、Windows資源監控中,如果DiskTime和Avg.DiskQueueLength的值很高,而PageReads/sec頁面讀取操作速率很低,則可能存在磁碟瓶徑。

負載壓力測試壓力測試工具軟體
I/O資源成為系統性能的瓶頸的徵兆:

過高的磁碟利用率(highdiskutilization);

太長的磁碟等待隊列(largediskqueuelength);

等待磁碟I/O的時間所佔的百分率太高(largepercentageoftimewaitingfordiskI/O);

太高的物理I/O速率:largephysicalI/Orate(notsufficientinitself);

過低的緩存命中率(lowbuffercachehitratio(notsufficientinitself));

太長的運行進程隊列,但CPU卻空閑(largerunqueuewithidleCPU)。

4、資料庫伺服器:

SQLServer資料庫:

1、SQLServer資源監控中指標緩存點擊率(CacheHitRatio),該值越高越好。如果持續低於80%,應考慮增加內存。

2、如果FullScans/sec(全表掃描/秒)計數器顯示的值比1或2高,則應分析你的查詢以確定是否確實需要全表掃描,以及SQL查詢是否可以被優化。

3、NumberofDeadlocks/sec(死鎖的數量/秒):死鎖對應用程序的可伸縮性非常有害,並且會導致惡劣的用戶體驗。該計數器的值必須為0。

4、LockRequests/sec(鎖請求/秒),通過優化查詢來減少讀取次數,可以減少該計數器的值。

Oracle資料庫:

1、如果自由內存接近於0而且庫快存或數據字典快存的命中率小於0.90,那麼需要增加SHARED_POOL_SIZE的大小。

負載壓力測試負載壓力測試
快存(共享SQL區)和數據字典快存的命中率:

select(sum(pins-reloads))/sum(pins)fromv$librarycache;

select(sum(gets-getmisses))/sum(gets)fromv$rowcache;

自由內存:select*fromv$sgastatwherename=『freememory』。

2、如果數據的緩存命中率小於0.90,那麼需要加大DB_BLOCK_BUFFERS參數的值(單位:塊)。

緩衝區高速緩存命中率:selectname,valuefromv$sysstatwherenamein(『dbblockgets』,『consistentgets』『physicalreads』)HitRatio=1-(physicalreads/(dbblockgets+consistentgets))。

3、如果日誌緩衝區申請的值較大,則應加大LOG_BUFFER參數的值。

日誌緩衝區的申請情況:selectname,valuefromv$sysstatwherename=『redologspacerequests』。

4、如果內存排序命中率小於0.95,則應加大SORT_AREA_SIZE以避免磁碟排序。

內存排序命中率:selectround((100*b.value)/decode((a.value+b.value),0,1,(a.value+b.value)),2)fromv$sysstata,v$sysstatbwherea.name=』sorts(disk)』andb.name=』sorts(memory)』

註:上述SQLServer和Oracle資料庫分析,只是一些簡單、基本的分析,特別是Oracle資料庫的分析和優化,是一門專門的技術,進一步的分析可查相關資料。

6 負載壓力測試 -參考資料

1、http://www.51testing.com/?action_viewnews_itemid_20802.html
2、http://www.cnblogs.com/simpsons/archive/2007/09/18/896532.html

上一篇[斯托克斯線]    下一篇 [阿希爾]

相關評論

同義詞:暫無同義詞