web系統後端接口壓測報告

原創 罗星星的博客 2020-06-19 10:19

文章目錄

一、測試目的

針對uat環境的用戶併發量和系統瓶頸，都是未知的。
本輪壓力測試，抽取部分代表性查詢接口，主要是爲了測試後臺系統UAT環境主要接口吞吐量和響應時間，初步找出系統的瓶頸。

二、測試內容

壓測接口清單

  • api/nonmetalPla/list（pla(post)）
  • api/warehouse/searchCarType （查詢基礎數據(post) ）
  • api/dict/findDictByParentCode （根據父類編碼查詢下級字典(post) ）
  • 壓測數據庫查詢m_dict數據 （jdbc連接 ）

三、測試環境

環境 機器型號 CPU 操作系統 內存 磁盤
應用服務器 linux虛擬機 CPUIntel® Xeon® Gold 6132 CPU @ 2.60GHz
4個單核四線程		 CentOS Linux release 7.5.1804 (Core) 單機 total：8G ，可用內存： free+buffers/cached = 2.3G tatal：26G used：15G
壓測機器 宏碁4750 單個雙核四線程 win10 單機 8G total:8G used:3G

四、測試方法

4.1、壓測工具和指標

類別 說明
壓測工具 apache-jmeter-5.1.1（單臺win環境）
壓測性能相關參數 協議: http
方法: get/post
併發數 、總請求數、吞吐率(TPS)、響應時間、錯誤率

4.2、測試時間

第一輪壓測：
測試時間：9:00-12:00（工作時間） ，內網環境壓測（VPN內網，非完全內網）
針對每個接口分別執行併發數10、30、90、270併發數執行120秒
第二輪壓測：
測試時間：7:50-09:30（工作時間） ，內網環境壓測（VPN內網，非完全內網）
針對每個接口分別執行併發數10、30、90、270併發數執行120秒
第三輪壓測：
測試時間：09:00-09:30（工作時間） ，內網環境壓測（VPN內網，非完全內網）
針對pla接口30併發數執行120秒

五、統計指標

進行壓力測試，並對產生的每秒TPS，響應時間（min，ave，max）及錯誤率進行統計

六、測試結果

6.1、第一輪壓測

時間：9:00-12:00（工作時間）

6.1.1、聚合報告
接口名稱 數據量 併發數 持續時間 samples average min max median 90%Line 95%Line 99%Line error% tps(s) received(kb/s) sent(kb/s)
pla(post) limit 10 120s
api/nonmetalPla/list 10 5113 233 73 2458 191 345 408 827 0 42.41921434 1672.45209 21.91383241
api/nonmetalPla/list 30 5323 673 146 8692 543 1196 1561 2619 0 43.96775313 1733.505954 22.71380996
api/nonmetalPla/list 90 6224 1737 161 26447 1262 3238 4445 8283 0 49.34982556 1945.703621 25.49419699
api/nonmetalPla/list 270 7586 4298 155 44290 3359 7611 9445 15606 0 59.22213375 2334.936724 30.59424683
查詢基礎數據(post) limit 10
/api/warehouse/searchCarType 10 2602 459 113 3458 393 692 937 1496 0 21.5274388 1078.600366 11.28929163
/api/warehouse/searchCarType 30 4456 805 105 7980 670 1369 1712 2686 0 36.9694355 1852.298689 19.38729186
/api/warehouse/searchCarType 90 5044 2150 172 11822 1781 3441 4277 6622 0 41.092654 2058.886432 21.54956562
/api/warehouse/searchCarType 270 6504 5022 154 79084 3997 8100 10222 17749 0 51.1437356 2562.480956 26.82049416
根據父類編碼查詢下級字典(post) limit 10
/api/dict/findDictByParentCode 10 652 1842 225 12681 1505 2617 5084 6542 0 5.201643464 3.682313378 2.722735251
/api/dict/findDictByParentCode 30 1942 1861 267 11447 1489 3467 4896 6968 0 15.58337346 10.10484372 8.156922043
/api/dict/findDictByParentCode 90 5464 1986 284 23215 1604 2840 5219 6941 0 43.72669217 28.97468862 22.88819043
/api/dict/findDictByParentCode 270 16931 1921 72 14632 1505 3356 5021 6597 1.07 131.6268411 88.65045632 68.13092412
jdbc連接 limit 10
壓測數據庫查詢m_dict數據 10 17390 66 10 13343 40 116 179 312 0 145.2 145.46 0
壓測數據庫查詢m_dict數據 30 18909 181 10 8165 118 351 474 845 0 157.5 157.78 0
壓測數據庫查詢m_dict數據 90 15052 709 13 12010 538 1106 1566 6648 0.48 125.1 124.78 0
壓測數據庫查詢m_dict數據 270 19391 1681 13 10848 1517 2593 3232 7707 0 158.1647635 158.47 0
6.1.2、接口壓測實況圖（90併發）

下面抽取併發量爲90的情況下各個測試接口的資源情況，分別是內存和cpu狀況圖、響應時間、tps
在這裏插入圖片描述
在這裏插入圖片描述

一、api/nonmetalPla/list((post)）

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
二、/api/warehouse/searchCarType （查詢基礎數據(post) ）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
三、/ api/dict/findDictByParentCode （根據父類編碼查詢下級字典(post) ）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
四、壓測數據庫查詢m_dict數據 （jdbc連接 ）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

6.1.3、第一輪壓測分析
  • 帶寬、內存、內存、磁盤等指標在網頁查看一直表現的比較正常，在命令行直接進去服務器查看，cpu有超過100%的幾次狀況。
  • 併發數在90以內時，接口響應時間基本能保證在2s內
  • 普通數據庫查詢接口tps有提升空間，pla接口在10-270的併發下均能保持40tps以上
  • warehouse查詢(post) 接口相比pla接口仍較慢，可做進一步優化，考慮字段過多，sql查詢方面的問題
  • 根據父類編碼查詢下級字典(post)接口耗時非常嚴重，需要比較優先優化，考慮索引和sql方面的問題
  • 數據庫壓測tps只有120-150左右，需要進一步提高，考慮服務器性能方面和mysql配置問題，在非工作時間有嘗試壓測
  • 對於接口耗時較長的情況，目前引入了redis，但是目前用的地方很少，redis幾乎閒置，接口可以考慮結合使用redis

一次壓測數據不一定是準確的，有主要以下幾點

  • 服務器網絡變化
  • 服務器性能改變
  • 壓測主機網絡變化
  • DB數據量的變化
  • 壓測過程中部分請求 error / 超時影響

6.2、第二輪壓測

壓測時間：07:50-9:30（工作時間）

6.2.1、聚合報告
接口名稱 數據量 併發數 持續時間 samples average min max median 90%Line 95%Line 99%Line error% tps(s) received(kb/s) sent(kb/s)
pla(post) limit 10 120s
api/nonmetalPla/list 10 TOTAL 4038 296 95 9299 233 496 630 934 0 33.49841965 1330.286362 17.30533593
api/nonmetalPla/list 30 TOTAL 5134 698 76 7882 602 921 1107 3601 0 42.68835175 1695.236156 22.05286921
api/nonmetalPla/list 90 TOTAL 5830 1873 157 12518 1717 2293 3515 5551 0 47.52472019 1887.297604 24.55134471
api/nonmetalPla/list 270 TOTAL 5130 6483 459 26515 5727 10125 11911 16345 0 40.1323664 1593.733086 20.73244319
basedata(post) limit 10
/api/warehouse/searchCarType 10 TOTAL 4272 451 94 17898 426 615 676 853 0.002340824 22.09544695 2040.372722 11.56003959
/api/warehouse/searchCarType 30 TOTAL 3028 1186 187 4492 1120 1586 1807 2567 0 25.12883924 2325.840943 13.17791667
/api/warehouse/searchCarType 90 TOTAL 2146 5096 264 37961 3563 10678 14950 24020 0 16.60528026 1536.928958 8.708042481
/api/warehouse/searchCarType 270 TOTAL 2916 11779 257 55320 10512 17029 20018 27637 0 21.09649694 1952.620886 11.06329966
根據父類編碼查詢下級字典(post) limit 10
/api/dict/findDictByParentCode 10 TOTAL 31344 37 19 3256 28 37 56 245 0 261.1586499 392.5030881 136.7002308
/api/dict/findDictByParentCode 30 TOTAL 69339 51 21 7120 42 58 132 215 0 577.6083969 868.1048074 302.3418952
/api/dict/findDictByParentCode 90 TOTAL 87335 122 22 14538 94 219 274 500 0 727.2886254 1093.063666 380.6901398
/api/dict/findDictByParentCode 270 TOTAL 94655 339 22 6125 296 451 496 1331 0 786.713432 1182.374973 411.7953121
jdbc連接 limit 10
壓測數據庫查詢m_dict數據 10 查詢 43653 24 9 4549 18 30 44 139 0 363.6689299 364.3792208 0
壓測數據庫查詢m_dict數據 30 查詢 19069 187 20 22843 83 341 521 981 0 158.7694101 159.0795066 0
壓測數據庫查詢m_dict數據 90 查詢 31774 333 10 9448 231 576 805 1814 0 264.096682 264.6124958 0
壓測數據庫查詢m_dict數據 270 查詢 27057 1196 26 15632 902 2004 2398 4520 0 222.8252366 223.2604421 0
6.2.2、接口壓測實況圖（90併發）

下面抽取併發量爲90的情況下各個測試接口的資源情況，分別是內存和cpu狀況圖、響應時間、tps
在這裏插入圖片描述
在這裏插入圖片描述
一、api/nonmetalPla/list((post)）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
二、/api/warehouse/searchCarType （查詢基礎數據(post) ）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
三、/ api/dict/findDictByParentCode （根據父類編碼查詢下級字典(post) ）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
四、壓測數據庫查詢m_dict數據 （jdbc連接 ）
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

6.2.3、第二輪壓測分析
  • 二輪壓測發現pla接口和warehouse接口都是比較相近的tps結果數據，
  • 數據字典接口翻了將近10倍，其數據也是不多的，但是結果差別如此的大。
  • 壓測數據庫查詢tps也翻了一倍，
    根據以上幾個現象，首先能確定的是雖然內網環境，但是走vpn的情況下，網絡存在不穩定，當前數據庫僅該後臺系統在使用，說明數據傳輸的耗時主要受網絡方面的影響大。
    結合第一輪壓測出現的一些問題，兩輪下來，需要第三輪的測試，
    第三輪主要是判斷數據量大小的網絡傳輸，是否明細影響壓測結果

6.3、第三輪壓測

6.3.1、聚合報告
接口名稱 數據量 併發數 持續時間 samples average min max median 90%Line 95%Line 99%Line error% tps(s) received(kb/s) sent(kb/s)
pla(post)
api/nonmetalPla/list 10 30 120s 5207 689 74 5609 608 1054 1356 2167 0 43.3 1717.91 22.35
api/nonmetalPla/list 1 30 120s 17408 205 48 5707 113 317 472 2120 0 144.8 629.9 74.65
api/nonmetalPla/list 0 30 120s 47035 75 24 21001 52 120 187 321 0 391.8 171.41 208.88

在這裏插入圖片描述

6.3.2、接口壓測實況圖（30併發）

下面抽取併發量爲30壓測的情況下各個測試接口的資源情況，分別是內存和cpu狀況圖、響應時間、tps
壓測接口：api/nonmetalPla/list((post)
併發量：30
在這裏插入圖片描述
在這裏插入圖片描述

一、查詢0條
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
二、查詢1條
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
三、查詢10條
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述

6.3.3、第三輪壓測分析
  • 數據量大小的網絡傳輸影響非常大
  • 數據量越小傳輸越快，當前VPN的內網受VPN或內網網速影響較大
  • 接口的數據量有必要縮減，會有明細的tps提升

七、結論

結合壓測一、二、三分析，得到以下一些結論和建議：

  • 主要問題在網絡環境，網絡的提升對壓測tps的影響非常大。

  • 工作時間的早上剛上班期間，服務器和帶寬都是比較寬裕的狀況，這幾個目標接口的壓測結果tps都提高了很多，vpn連接的內網壓測對數據的準確性仍然有一定的影響

  • 在網絡正常的情況下，接口tps仍然只能在50左右。

  • 服務器性能不是非常穩定，虛擬linux多個地方共用主機導致有波動，也影響接口性能，單獨部署到一臺服務器會事比較好的選擇

  • 數據庫壓測tps120-150，200+均出現，從二輪壓測可以看出，除了網絡之外，數據庫tps仍可以繼續提高，本地機器能達到1000tps，可以向着這個目標接近。

  • 所有接口不需要的字段儘量縮減不返回到前端，可做進一步優化，考慮字段過多，sql查詢方面的問題

  • 對於接口耗時較長的情況，目前引入了redis，但是目前用的地方很少，redis幾乎閒置，接口可以考慮結合使用redis

  • 考慮下一輪的壓測中直接在機房另一臺linux/win下專門壓測，並使用命令行方式直接導出報告的方式節省工作量

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

軟件測試基礎之性能測試(一)概念

以下均爲個人理解，只做參考，如有錯誤或疑惑，請留言或私信 什麼是性能測試？ 性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。

噢_乖 2020-07-07 14:29:30

（七）關聯和斷言

一.關聯 哪些數據需要關聯 數據是由服務器端生成的 數據在每一次請求時都是動態變化的 數據在後續的請求中需要再發送出去 舉個栗子， 常見的 Session ID 就是一個典型的需要關聯的數據。它需要在交互過程中標識一

王昱儿 2020-07-08 11:44:43

性能測試常見現象之tps波動頻繁定位技巧

前言：前段時間，壓測遇到一個問題，在壓測的時候，tps波動很頻繁。 使用xshell遠程連接到應用服務器，通過top命令看了下服務器資源情況，cpu波動也很頻繁，其它服務器都正常。 打開JvisualVM，雙擊對應的應用進程 然

Detail-L 2020-07-08 01:10:43

lr_eval_string;sprintf;lr_save_string;用法

一、lr_save_string 使用介紹1.該函數主要是將程序中的常量或變量保存爲lr中的參數。格式： //將常量保存爲參數 lr_save_string("777","page"); web_url(http://www.sin

wan_xie2009 2020-07-07 20:23:39

性能測試-- -08jmeter腳本開發

jmeter腳本開發 HTTP協議解讀爲什麼要去了解協議呢？ 你要去找妹子，你連妹子的愛好都不知道，她喜歡喫辣的，你天天帶她喫上海菜，是不是就黃了 有一個坑：就是有很多請求是有重定向的 一個請求發出去。響應會有3個，或者多個（查看

一手代码，一手诗 2020-07-07 15:55:33

查找瓶頸時按以下順序，由易到難。

    服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）     注：以上過程並不是每個分析中

alisisuli 2020-07-07 06:15:34

k6新一代性能測試工具

性能測試工具的現狀 在軟件測試界，只要一提起來性能測試工具，大家甭管是做個性能測試的，還是沒做過性能測試的，大多數都能異口同聲的說出來兩個重量級工具，LoadRunner和Jmeter。一個代表了商業性能測試工具的巔峯，一個帶走了了當今大

智慧保罗 2020-07-06 21:26:28

QPS、TPS、併發用戶數、吞吐量之間有什麼聯繫，存在什麼關係？

前言：QPS、TPS、併發用戶數、吞吐量之間的關係你真的懂麼？ 1、QPS QPS Queries Per Second 是每秒查詢率 ,是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量

Detail-L 2020-07-06 18:13:35

性能測試-- -07jmeter主要元件（測試計劃元件和線程組元件）剖析

jmeter主要元件剖析 線程組元件 斷言元件 監控元件 定時器元件 邏輯元件 1.線程組元件 只要用jmeter，這個元件就用 獨立運行每一個線程組？ 這個勾，如果不勾的話 多個線程組就是一起跑 這個勾，如果勾的話 多個線程組就

一手代码，一手诗 2020-07-06 13:34:58

性能測試-- -06企業案列解讀與技術昇華

企業案列解讀與技術昇華 性能測試常見的問題 一：如何避免負載機不休眠或者中途中斷？ 1.電源不中斷 2.負載機：一般是用命令行，沒有GUI界面的（一般用圖形化界面調試好，然後都是用命令行跑的） 但是用命令行跑，有一個致命的問題。

一手代码，一手诗 2020-07-06 07:18:23

(Jmeter 六) 參數行

準備： 將數據以utf-8的編碼形式保存在para.txt文檔中，內容如下： userid1,pwd1 userid2,pwd2 方法一：函數助手 點擊菜單欄“選項”---->函數助手對話框 複製生成的參數化函數，打開登陸請求頁面，在右

fanxiyanhong 2020-07-05 16:34:32

Jmeter 相關元祖參數

1、線程組 每個測試計劃至少需要包含一個線程組，在測試計劃下面多個線程是並行執行的，也就是說這些線程組是同時被初始化並同時執行線程組下的Sampler的。 屬性詳解： 線程數：虛擬用戶數。一個虛擬用戶佔用一個進程或線程。設置多少虛擬用戶數

fanxiyanhong 2020-07-05 16:34:32

利用Flask封裝sqladvisor服務

利用Flask封裝sqladvisor服務 使用sqladvisor需要預裝很多系統組件，比如percona等，在不連外網的情況下，安裝起來還是非常困難的。於是採用鏡像的方式安裝，這樣就存在一個遠程調用sqladvisor的問題，

百年黑店 2020-07-05 11:25:35

利用線性擬合模型預測SQL性能隱患

#利用線性擬合模型發現測試環境性能隱患 ##一個經典的性能問題 投產後數週，生產環境出現了系統響應緩慢、數據庫負載衝高、大量數據庫連接不釋放的生產事件，問題原因是由於一張表的數據量在投產後持續增長，且有聯機語句使用了全表掃描訪問了

百年黑店 2020-07-05 11:25:35

LR中錯誤代號爲27796的一個解決方法－Zee

  問題：   曾經遇到過一個問題，在一次性能測試過程中，使用http協議的多用戶向服務器發送請求。設置了持續時間，出現錯誤爲：27796, Failed to connect to server 'hostname';port_ld'

高楼Zee 2020-07-05 10:47:46