性能測試報告

接口性能測試報告Rev：A.1編制軟件測試工程師***日期批準(zhǔn)架構(gòu)師***日期Page(Page(#)of(17)目錄TOC\o"1-5"\h\z\o"CurrentDocument"1.概述31.1目的3\o"CurrentDocument"1.2術(shù)語3\o"CurrentDocument"1.3參考資料3第1章需求分析錯誤!未定義書簽。2.項目背景錯誤!未定義書簽。2.1部署結(jié)構(gòu)圖錯誤!未定義書簽。2.2系統(tǒng)架構(gòu)圖錯誤!未定義書簽。TOC\o"1-5"\h\z測試資源5\o"CurrentDocument"3.1測試環(huán)境5\o"CurrentDocument"3.2人力資源53.3測試工具錯誤!未定義書簽。(1)Jemeter工具介紹錯誤!未定義書簽。(2)工作原理錯誤!未定義書簽。(4)Jmeter圖表指標(biāo)說明錯誤!未定義書簽。JVM監(jiān)控工具錯誤!未定義書簽。服務(wù)器資源監(jiān)控工具錯誤!未定義書簽。測試策略6測試目標(biāo)錯誤!未定義書簽。測試方法錯誤!未定義書簽。測試內(nèi)容錯誤!未定義書簽。缺陷處理規(guī)范錯誤!未定義書簽。測試產(chǎn)物錯誤!未定義書簽。5.測試計劃錯誤!未定義書簽。6.風(fēng)險分析131概述1.1該文檔詳細描述壓力測試過程、測試監(jiān)控數(shù)據(jù)以及測試數(shù)據(jù)分析結(jié)論。1.2術(shù)語負載測試：通過測試工具不斷增大壓力，查看系統(tǒng)性能表現(xiàn)的一個測試過程。負載機：發(fā)送請求，生產(chǎn)測試壓力的機器。1.3參考資料《》測試需求2.1被測系統(tǒng)分析**是一個試點項目，**正在接入到**項目中來，通過**系統(tǒng)可以直接進入到**平臺。后續(xù)用戶量會隨著**系統(tǒng)用戶的接入逐漸增大。11月**系統(tǒng)會展示到互聯(lián)網(wǎng)大會上0，預(yù)計互聯(lián)網(wǎng)大會訪問量會到達一萬以上，這么大的用戶訪問量必然對我們的系統(tǒng)造成很大的考驗。當(dāng)前**部署在一臺2核4G的阿里云服務(wù)器上，在這樣低的性能機器上系統(tǒng)能處理很大

的并發(fā)是不可能的。目前系統(tǒng)注冊和使用用戶非常少，并不會對系統(tǒng)造成威脅。但是系統(tǒng)的

處理效率、容量和穩(wěn)定性未經(jīng)過驗證，還不確定系統(tǒng)在單服務(wù)器的效率、容量和穩(wěn)定性。測試通過標(biāo)準(zhǔn)通過指標(biāo)錯誤率<5%響應(yīng)時間<5sCPU<75%內(nèi)存<75%測試前置操作3.1測試環(huán)境首先測試服務(wù)器有限，沒有獨立的服務(wù)器供壓測使用。其次**線上用戶量非常少，壓測非訂單業(yè)務(wù)接口不影響生產(chǎn)環(huán)境的運行，所以選擇合適的時間在生產(chǎn)環(huán)境下直接壓測。系統(tǒng)的api接口、dubbo月服務(wù)和mysql服務(wù)器都在同一臺月服務(wù)器，配置都是默認的，沒有經(jīng)過優(yōu)化。性能測試環(huán)境jdk版本jdk1.8部署容器apache-tomcat-8測試工具Jmeter3.2Jmeter負載服務(wù)器4核8GCentOS64位4臺mysql數(shù)據(jù)庫月服務(wù)器4核8GCentOS64位1臺Web應(yīng)用月服務(wù)器與數(shù)據(jù)庫月服務(wù)器共用測試腳本如下附件：基礎(chǔ)數(shù)據(jù)沒有歷史數(shù)據(jù)可以參考，不需要構(gòu)造基礎(chǔ)數(shù)據(jù)，直接使用生產(chǎn)環(huán)境已有的數(shù)據(jù)。3.4人力資源測試1人、后臺服務(wù)開發(fā)1人。

序號角色人數(shù)職責(zé)1性能測試工程師1性能測試方案性能測試腳本性能執(zhí)行測試和分析性能測試報告2后臺月服務(wù)開發(fā)工程師1協(xié)查性能測試過程問題協(xié)助分析性能測試結(jié)果3.5負載場景配置配置項設(shè)置CC十C廠十Tr3000(3s)Ilillikiii1ie設(shè)乂i斷言ConstantTiiiieiResponseAssertion3000(3s)斷言集合點設(shè)置L-z1i\1L1L-z11SynchronizingTimerNumberofSimulatedtoGroup1L>/\L1\L-z1~x-idkJx-JL1II1y并發(fā)數(shù)by3000(3s)H盯P請求默認值Cc小4-ii+3000(3s)10000(10s)ConnecttiiiieOutDz->r'r>z-\r^r'r>廠、ii十丄0000(10s)10000(10八ResponsetimieOutCd>十f十Mic丄0000(10s)i>tf8Lisenercontentencoding無支架使用-l生成csv文件，保存timeStamp,elapsed,label,responseCode,responseMessage,threadName,success,failureMessage,bytes,sentBytes,grpThreads,allThrea3.6測試監(jiān)控應(yīng)用服務(wù)器監(jiān)控：使用linux自帶的top、vmstat命令監(jiān)控服務(wù)器資源Tomcat的JVM監(jiān)控:使用jdk自帶的jmap、jstat查看內(nèi)存、線程、類的情況。數(shù)據(jù)庫監(jiān)控：沒有做監(jiān)控。后續(xù)可以增加慢查詢的跟蹤。負載機監(jiān)控：使用linux自帶的top、vmstat命令監(jiān)控服務(wù)器資源備注：由于是生產(chǎn)環(huán)境，所以沒有使用第三方工具進行監(jiān)控。

測試場景設(shè)計4.1測試場景壓測場景序號測試場景并發(fā)數(shù)備注2用100個并發(fā)壓測綜合業(yè)務(wù)，每個業(yè)務(wù)分配25個并發(fā).循環(huán)壓測20次100驗證腳本的正確性3用200個并發(fā)壓測綜合業(yè)務(wù)，每個業(yè)務(wù)分配50個并發(fā)，循環(huán)壓測20次200翻倍增大并發(fā)，檢驗系統(tǒng)的性能6用500個并發(fā)壓測綜合業(yè)務(wù)，每個業(yè)務(wù)分配125個并發(fā)，循環(huán)壓測20次500增大到500并發(fā)，檢驗系統(tǒng)的性能由于超時率高與預(yù)期，需要降低并發(fā)壓測，壓測過程中增加這二個場景。4用300個并發(fā)壓測綜合業(yè)務(wù)，每個業(yè)務(wù)分配75個并發(fā)，循環(huán)壓測20次300減小并發(fā)，檢驗系統(tǒng)的性能超時率是否有減少5用400個并發(fā)壓測綜合業(yè)務(wù)，每個業(yè)務(wù)分配100個并發(fā).循環(huán)壓測20次400增大并發(fā)，檢驗系統(tǒng)的性能7從20個并發(fā)開始測試，每隔10s鐘增加20個并發(fā)，逐漸增大到1000個并發(fā)，并持續(xù)壓測5分鐘。1000從0逐漸增大到1000，檢驗系統(tǒng)隨著并發(fā)的增大系統(tǒng)的處理效率是一個什么樣的反應(yīng)。4.2相關(guān)業(yè)務(wù)接口測試用例從**入口進入**首頁、商家詳情頁、商品詳情頁、商品列表、商家列表四個業(yè)務(wù)同時壓測，每個業(yè)務(wù)相關(guān)的接口按列表中的順序逐一請求。測試過程整個測試過程中5.1100個并發(fā)測試情況整個測試過程不管是錯誤率還是響應(yīng)時間都是正常,系統(tǒng)響應(yīng)很快，基本上小于400ms。6004002000D9;00WD9;05W0^10:00山匚tiveThreadsOverTimeC?：00：OW9：05：ODD9：10:00TransactionsPer5亡匚and0^:00:00DD:05:ODC9:10:MHitsPerSecond-CO50□09:CiO:000?:05:00D?:10:005.2200個并發(fā)測試情況翻倍增加了并發(fā)數(shù)后，系統(tǒng)的響應(yīng)有較大幅度的變厲害，部分接口響應(yīng)時間翻倍，但是整個過程中平均響應(yīng)時間小于2s，TPS（如圖4）有所增長，達到預(yù)定指標(biāo)。ResponseTimesOverTime10:32:0010：3+W10:36*0ActiveThreadsOverTmeResponseTimesOverTime10:32:0010：3+W10:36*0ActiveThreadsOverTme5.3500個并發(fā)測試情況繼續(xù)增大并發(fā)量，翻倍增加了并發(fā)數(shù)后，系統(tǒng)整體的性能變化很大TPS和流量吞吐量都沒有什么增長系統(tǒng)的響應(yīng)時間從原來小于2s到現(xiàn)在2s?10s之間超時率達到了4.43%。說明系統(tǒng)處理效率已經(jīng)達到了瓶頸。繼續(xù)減小并發(fā)查看系統(tǒng)的表現(xiàn)。5000011:20:0011:25:00托?！鋈絬ti常亡Th「亡ad呂匚Tim亡^1:20:00：2E：5000011:20:0011:25:00托?！鋈絬ti常亡Th「亡ad呂匚Tim亡^1:20:00：2E：C0fl500000250000BytesThroughputOverTme11;20;0011;25;0QTransaiztionsPerSecondPHitsPerSecond11:20:0011：25：005.4300個并發(fā)測試情況減少到300個并發(fā)后,系統(tǒng)的響應(yīng)時間、tps、流量吞吐量都跟200個并發(fā)差不多。繼續(xù)增大并發(fā)查看系統(tǒng)性能表現(xiàn)。ResponseTmesO^erTimeActiveThreadsOverTime500000250000BytesThroLFghputOverTinne-1：-3D：C-0-1ResponseTmesO^erTimeActiveThreadsOverTime500000250000BytesThroLFghputOverTinne-1：-3D：C-0-1：05：GO「mClJ1:0￡-:005.5400個并發(fā)測試情況增大到400個并發(fā)后，系統(tǒng)響應(yīng)時間有所增大，比300個并發(fā)慢2?3s。TPS比300個稍大，流量吞吐量沒什么大的變化。系統(tǒng)還是處理比較正常的。對比500個并發(fā)，也說明500個并發(fā)就是系統(tǒng)的瓶頸。ResponseTimesOverTimeActiv亡ThreadsOverTimeBytESThroughputCv亡「TimETranmmttiorimPerSecond53■^1:15:00J1：1C'：C'OHitsPerSecondResponseTimesOverTimeActiv亡ThreadsOverTimeBytESThroughputCv亡「TimETranmmttiorimPerSecond53■^1:15:00J1：1C'：C'OHitsPerSecondimeVsThreads5.61000個并發(fā)測試情況從20個并發(fā)，每10秒鐘增加20個并發(fā)，逐漸增大到1000個并發(fā)。從下面圖表可以看出響應(yīng)時間（圖1）逐漸的增大，當(dāng)增大到800個并發(fā)后，系統(tǒng)的響應(yīng)時間基本上都超過了10s，系統(tǒng)此時超時率非常大。在600個并發(fā)左右時系統(tǒng)的流量吞吐量、TPS并沒有繼續(xù)增大，開始保持平穩(wěn)的曲線。跟500個并發(fā)對比，可以說明500~600之間就是系統(tǒng)的瓶頸。再增大并發(fā)，系統(tǒng)已經(jīng)不能處理。系統(tǒng)隊列增大，失敗率增多。隨著并發(fā)的增大，系統(tǒng)在1000個并發(fā)下壓測5分鐘，系統(tǒng)并沒有奔潰。停止壓測后，重新訪問系統(tǒng)，系統(tǒng)還能正常響應(yīng)，說明系統(tǒng)是可恢復(fù)性的。5-30DOOActiveThreadsOverTimeTrarsactiansPerSecond□fIBytesThroughputOverTime250000DM：5C'5-30DOOActiveThreadsOverTimeTrarsactiansPerSecond□fIBytesThroughputOverTime250000DM：5C'：ij0-2：00：DD0^―T：5ij：C'O12：00WHitsPerSecond

000-1：5ijHitsPerSecond

000-1：5ij：G0^2:00:00RequestsSummary■KO■okQK7^15%5.7錯誤分析問題1：NonHTTPresponsecode:.SocketTimeoutException/NonHTTPresponsemessage:Readtimedout系統(tǒng)處理不了那么多情況，壓測請求連接不上服務(wù)。問題2：NonHTTPresponsecode:.SocketTimeoutException/NonHTTPresponsemessage:connecttimedout系統(tǒng)處理不了那么多情況，壓測請求連接不上服務(wù)。問題3:NonHTTPresponsecode:org.apache.http.NoHttpResponseException/NonHTTPresponsemessage::443failedtorespond系統(tǒng)處理不了那么多情況，系統(tǒng)超時。問題4：NonHTTPresponsecode:.SocketException/NonHTTPresponsemessage:Connectionreset系統(tǒng)處理不了那么多情況，壓測請求連接不上服務(wù)測試結(jié)論500~600之間就是系統(tǒng)的瓶頸。再增大并發(fā)，系統(tǒng)已經(jīng)不能處理。系統(tǒng)隊列增大，失敗率增多。隨著并發(fā)的增大，當(dāng)并發(fā)達到1000個時，80%的請求超時。在1000并發(fā)下壓測5分鐘，系統(tǒng)還在正常運行，系統(tǒng)能承受1000個并發(fā)的沖擊。建議：（1）優(yōu)化tomcat線程、內(nèi)存的配置。（2）為數(shù)據(jù)庫增加索引和緩存。（3）增加分布式部署。（4）再繼續(xù)幾輪壓測。風(fēng)險分析由于系統(tǒng)服務(wù)器沒有做全面