Mall商城的高級篇的開發（二）

性能壓測–壓力測試

壓力測試考察當前軟件硬件環境下系統所能承受的最大負荷并幫助找出系統的瓶頸所在。壓測都是為了系統在上線的處理能力和穩定性維持在一個標準的范圍內，做到心中有數。

使用壓力測試，我們有希望找到很多種用其他測試方法很難發現更多的錯誤。有兩種錯誤類型是：內存泄露、并發與同步。

有效的壓力測試系統將應用在一下這些關鍵條件：重復、并發、量級、隨機變化

性能指標

性能指標是來整體把握整個系統的狀況。

• 響應時間（Response Time:RT）:響應時間指用戶從客戶端發起一個請求開始，到客戶端接受到從服務器端返回的響應結束，整個過程所耗費的時間。
• HPS（Hits Per Second），每秒點擊次數，單位是次/秒。
• TPS（Transaction per Second），系統每秒處理交易數，單位是筆/秒。
• QPS（Query per Second）：系統每秒處理的查詢數，單位是次/秒。對于互聯網的業務中，如果某些業務有且僅有一個請求連接，那么TPS=QPS=HPS，一般情況下用TPS來衡量整個業務的流程，用QPS來衡量接口查詢次數，用HPS來表示對服務器的單擊請求。
• 無論TPS、QPS、HPS，此指標是衡量系統處理能力非常重要的指標，越大越好，根據經驗，一般情況下：
  • 金融行業：1000TPS～50000TPS，不包括互聯網化的活動
  • 保險行業：100TPS～100000TPS，不包括互聯網的活動
  • 制造行業：10TPS～5000TPS
  • 互聯網電子商務：10000TPS～10000000TPS
• 最大響應時間（Max Response Time）指用戶發出請求或者指令到系統作出反應（響應）的最大時間。
• 最少響應的時間（Mininum Response Time）指用戶發出請求或者指令到系統作出反應（響應）的最少時間
• 90%響應時間（90% Response Time）是指所有用戶的響應時間進行排序，第90%響應時間
• 從外部看，性能測試主要關注如下的指標
  • 吞吐量：每秒鐘系統能處理的請求數、任務數
  • 響應時間；服務處理一個請求或一個任務的耗時
  • 錯誤率：一批請求結果中出錯的請求所占的比例。

JMeter

安裝

官方下載地址：Apache JMeter - Download Apache JMeter

啟動命令。

JMeter壓測示例

編寫測試計劃。

添加用戶線程組。并配置用戶線程組的屬性。

給線程組添加配置元件中的HTTP請求默認值。并配置屬性。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-kukZVrjB-1652189323113)(/Users/wanglufei/Library/Application Support/typora-user-images/image-20220407152653269.png)]

給線程組添加取樣器中的HTTP請求。并配置屬性。因為我們在第三步，已經配置過了，這個就不用配置。

配置返回的結果。一個是查看結果樹、一個是聚合報告、用表格查看結果。

啟動測試。

壓測我們的首頁

壓測步驟

添加用戶線程，模擬用戶發起請求

配置HTTP請求

生成結果報告

壓測結果截圖

匯總報告

聚合報告

查看結果樹

匯總圖

影響性能的考慮點

數據庫、應用程序、中間件（tomcat、nginx）、網絡和操作系統等方面

優化的點：應該考慮自己的應用場景屬于CPU密集型還是IO密集型

性能監控

JVM內存模型

JVM的相關筆記：JVM_BearBrick0的博客-CSDN博客

堆

在堆內存中，存在幾乎90%的對象實例，所有的對象實例以及數組都要在堆上分配。堆是垃圾收集器管理的主要區域，也被稱為GC堆；也是我們優化考慮最多的地方。

堆的劃分可以參考上面提出的相關筆記。

堆的一次性完成GC的流程：

后面會總結完成的GC流程，先立個Flag。

在做壓力測試期間，我們應該對堆中內存來進行監控，包括CPU線程等指標。

JConsole與JVisualvm

JDK的兩個小工具JConsole、JVisualvm（升級版的Jconsole），通過命令行啟動，可監控本地和遠程應用。遠程應用需要配置

JConsole

在命令行使用Jconsole，命令便可彈出控制面板：

找到我們的Product服務

概覽圖

內存使用率的圖

Jvisualvm

可以監控內存泄漏，跟蹤垃圾回收，執行時內存、CPU分析、線程分析…

使用JMeter做壓力測試，并做性能監控

整個項目的訪問流程圖

測試我們的中間件Nginx

編寫測試計劃，和上面的步驟相差不大，需要注意的是需要配置自己Nginx的IP地址。

監控Nginx的狀態

docker stats

測試結果：

出現的異常

結果報告

測試我們的網關服務Gateway

接口的壓力測試步驟和上面類似，這里監控CPU和內存的使用情況我們使用visualvm：

這里主要監控CPU和內存的使用情況

編寫簡單服務測試

@GetMapping("/hello") @ResponseBody public String hello() {return "hello"; }

壓測的數據表格

壓測內容壓測線程數吞吐量/s90%響應時間百分比99%響應時間百分比

Nginx	50 一直循環	25998	3	7
Gateway	50 一直循環	27823	2	8
測試簡單服務	50 一直循環	38513	2	6
Gateway+簡單服務	50 一直循環	12693	5	57
全鏈路	50 一直循環	1008	68	321
首頁渲染一級菜單	50 一直循環	264（db、thymeleaf）	90	234
三級分類的數據獲取	50 一直循環	27（db、thymeleaf）	2523	3295
首頁全量數據的獲取	50 一直循環	2（靜態資源）、（優化之后）19	38881	429
首頁渲染（開啟緩存、優化數據庫（給字段加索引）、降級日志的界別）	50 一直循環	280	388	1547
三級分類的數據獲取（優化查詢的業務邏輯）	50 一直循環	467	219	335

根據數據可以看出，我們應該優化的一個方向：

• 中間件越多，性能損失越大，大多數的原因都是由于網絡之間的耗時
• 業務
  • 模版引擎的渲染速度（緩存的開啟）
  • db（Mysql的優化）
    • 給字段建立普通索引
  • 靜態資源

JVM分析和調優

結合JvisualVm來給伊甸園和老年代分配合理的內存空間，主要目的是來減少Yong GC和Full Gc所帶來的時間的消耗。

Nginx的動靜分離

為了減少Tomcat的壓力，將靜態的配置文件都放到Nginx服務器中。來增加整體項目的

整體的效果圖：

流程圖：

效果圖：

操作流程

將靜態的文件移動到Nginx的服務器

配置Nginx的響應的配置文件

模擬線上應用內存奔潰宕機

由于我們將靜態的文件都分配到了Nginx服務器中，而Tomcat只接受我們動態的請求，也就是做了動靜分離的效果，我們來看看吞吐量有沒有提升。

同時為了測試線上的真實效果，我們選擇打開thymelead的緩存。

總結

以上是生活随笔為你收集整理的Mall商城的高级篇的开发（二）性能压测和性能监控的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。