性能測試報(bào)告(共19頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上接口性能測試報(bào)告Rev：A.1編制軟件測試工程師*日期批準(zhǔn)架構(gòu)師*日期專心-專注-專業(yè)目錄1 概述1. 1 目的該文檔詳細(xì)描述壓力測試過程、測試監(jiān)控?cái)?shù)據(jù)以及測試數(shù)據(jù)分析結(jié)論。1.2 術(shù)語負(fù)載測試： 通過測試工具不斷增大壓力，查看系統(tǒng)性能表現(xiàn)的一個(gè)測試過程。負(fù)載機(jī)：發(fā)送請求，生產(chǎn)測試壓力的機(jī)器。1.3 參考資料2. 測試需求2.1被測系統(tǒng)分析*是一個(gè)試點(diǎn)項(xiàng)目，*正在接入到*項(xiàng)目中來，通過*系統(tǒng)可以直接進(jìn)入到*平臺。后續(xù)用戶量會隨著*系統(tǒng)用戶的接入逐漸增大。11月*系統(tǒng)會展示到互聯(lián)網(wǎng)大會上0，預(yù)計(jì)互聯(lián)網(wǎng)大會訪問量會到達(dá)一萬以上，這么大的用戶訪問量必然對我們的系統(tǒng)造成很大的

2、考驗(yàn)。當(dāng)前*部署在一臺2核4G的阿里云服務(wù)器上，在這樣低的性能機(jī)器上系統(tǒng)能處理很大的并發(fā)是不可能的。目前系統(tǒng)注冊和使用用戶非常少，并不會對系統(tǒng)造成威脅。但是系統(tǒng)的處理效率、容量和穩(wěn)定性未經(jīng)過驗(yàn)證，還不確定系統(tǒng)在單服務(wù)器的效率、容量和穩(wěn)定性。2.2 測試通過標(biāo)準(zhǔn)通過指標(biāo)錯(cuò)誤率<5%響應(yīng)時(shí)間<5sCPU<75%內(nèi)存<75%3. 測試前置操作第1章 3.1 測試環(huán)境首先測試服務(wù)器有限，沒有獨(dú)立的服務(wù)器供壓測使用。其次*線上用戶量非常少，壓測非訂單業(yè)務(wù)接口不影響生產(chǎn)環(huán)境的運(yùn)行，所以選擇合適的時(shí)間在生產(chǎn)環(huán)境下直接壓測。系統(tǒng)的api接口、dubbo服務(wù)和mysql服務(wù)器都在同一臺服

3、務(wù)器，配置都是默認(rèn)的，沒有經(jīng)過優(yōu)化。性能測試環(huán)境jdk版本jdk1.8部署容器apache-tomcat-8測試工具Jmeter3.2Jmeter負(fù)載服務(wù)器4核8G CentOS 64位 4臺mysql數(shù)據(jù)庫服務(wù)器4核8G CentOS 64位 1臺Web應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器共用3.2 測試腳本如下附件：3.3 基礎(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í)行測試和分析性能測試報(bào)告2后臺服務(wù)開發(fā)工程師1協(xié)查性能測試過程問題協(xié)助分析性能測試結(jié)果3.5 負(fù)

4、載場景配置3.6 測試監(jiān)控（1） 應(yīng)用服務(wù)器監(jiān)控：使用linux自帶的top、vmstat命令監(jiān)控服務(wù)器資源（2） Tomcat的JVM監(jiān)控：使用jdk自帶的jmap、jstat查看內(nèi)存、線程、類的情況。（3） 數(shù)據(jù)庫監(jiān)控：沒有做監(jiān)控。后續(xù)可以增加慢查詢的跟蹤。（4） 負(fù)載機(jī)監(jiān)控：使用linux自帶的top、vmstat命令監(jiān)控服務(wù)器資源備注：由于是生產(chǎn)環(huán)境，所以沒有使用第三方工具進(jìn)行監(jiān)控。4. 測試場景設(shè)計(jì)4.1 測試場景4.2 相關(guān)業(yè)務(wù)接口4.3 測試用例從*入口進(jìn)入*首頁、商家詳情頁、商品詳情頁、商品列表、商家列表四個(gè)業(yè)務(wù)同時(shí)壓測，每個(gè)業(yè)務(wù)相關(guān)的接口按列表中的順序逐一請求。5. 測試過程

5、整個(gè)測試過程中5.1 100個(gè)并發(fā)測試情況整個(gè)測試過程不管是錯(cuò)誤率還是響應(yīng)時(shí)間都是正常，系統(tǒng)響應(yīng)很快，基本上小于400ms。5.2 200個(gè)并發(fā)測試情況翻倍增加了并發(fā)數(shù)后，系統(tǒng)的響應(yīng)有較大幅度的變厲害，部分接口響應(yīng)時(shí)間翻倍，但是整個(gè)過程中平均響應(yīng)時(shí)間小于2s，TPS（如圖4）有所增長，達(dá)到預(yù)定指標(biāo)。5.3 500個(gè)并發(fā)測試情況繼續(xù)增大并發(fā)量，翻倍增加了并發(fā)數(shù)后，系統(tǒng)整體的性能變化很大TPS和流量吞吐量都沒有什么增長，系統(tǒng)的響應(yīng)時(shí)間從原來小于2s到現(xiàn)在2s10s之間，超時(shí)率達(dá)到了4.43%。說明系統(tǒng)處理效率已經(jīng)達(dá)到了瓶頸。繼續(xù)減小并發(fā)查看系統(tǒng)的表現(xiàn)。5.4 300個(gè)并發(fā)測試情況減少到300個(gè)并發(fā)

6、后，系統(tǒng)的響應(yīng)時(shí)間、tps、流量吞吐量都跟200個(gè)并發(fā)差不多。繼續(xù)增大并發(fā)查看系統(tǒng)性能表現(xiàn)。5.5 400個(gè)并發(fā)測試情況增大到400個(gè)并發(fā)后，系統(tǒng)響應(yīng)時(shí)間有所增大，比300個(gè)并發(fā)慢23s。TPS比300個(gè)稍大，流量吞吐量沒什么大的變化。系統(tǒng)還是處理比較正常的。對比500個(gè)并發(fā)，也說明500個(gè)并發(fā)就是系統(tǒng)的瓶頸。5.6 1000個(gè)并發(fā)測試情況從20個(gè)并發(fā)，每10秒鐘增加20個(gè)并發(fā)，逐漸增大到1000個(gè)并發(fā)。從下面圖表可以看出響應(yīng)時(shí)間（圖1）逐漸的增大，當(dāng)增大到800個(gè)并發(fā)后，系統(tǒng)的響應(yīng)時(shí)間基本上都超過了10s，系統(tǒng)此時(shí)超時(shí)率非常大。在600個(gè)并發(fā)左右時(shí)系統(tǒng)的流量吞吐量、TPS 并沒有繼續(xù)增大，開

7、始保持平穩(wěn)的曲線。跟500個(gè)并發(fā)對比，可以說明500600之間就是系統(tǒng)的瓶頸。再增大并發(fā)，系統(tǒng)已經(jīng)不能處理。系統(tǒng)隊(duì)列增大，失敗率增多。隨著并發(fā)的增大，系統(tǒng)在1000個(gè)并發(fā)下壓測5分鐘，系統(tǒng)并沒有奔潰。停止壓測后，重新訪問系統(tǒng)，系統(tǒng)還能正常響應(yīng)，說明系統(tǒng)是可恢復(fù)性的。5.7 錯(cuò)誤分析問題1：Non HTTP response code: .SocketTimeoutException/Non HTTP response message: Read timed out系統(tǒng)處理不了那么多情況，壓測請求連接不上服務(wù)。問題2：Non HTTP response code: .SocketTimeoutE

8、xception/Non HTTP response message: connect timed out系統(tǒng)處理不了那么多情況，壓測請求連接不上服務(wù)。問題3：Non HTTP response code: org.apache.http.NoHttpResponseException/Non HTTP response message: :443 failed to respond系統(tǒng)處理不了那么多情況，系統(tǒng)超時(shí)。問題4：Non HTTP response code: .SocketException/Non HTTP response message: Connection reset系統(tǒng)處理不了那么多情況，壓測請求連接不上服務(wù)。6. 測試結(jié)論500600之間就是系統(tǒng)的瓶頸。再增大并發(fā)，系統(tǒng)已經(jīng)不能處理。系統(tǒng)隊(duì)列增大，失敗率增多。隨著并發(fā)的增大，當(dāng)并發(fā)達(dá)到1000個(gè)時(shí)，80%的請求超時(shí)。在1000并發(fā)下壓測5分鐘，系統(tǒng)還在正常運(yùn)行，系統(tǒng)能