48 張圖 | 實戰詳解微服務性能監控、Jmeter壓測、JVM調優

點擊“ 程序員內點事 ”關注,選擇“ 設置星標 ”

堅持學習,好文每日送達!


一、何爲壓力測試

1.1、 大白話解釋

  • 性能壓測是什麼:就是考察當前軟件硬件環境下,系統所能承受的最大負荷,並幫助找出系統的瓶頸所在。

  • 性能壓測的目的:爲了系統在線上的處理能力穩定性維持在一個標準範圍內,做到知己知彼,百戰不殆。還可以發現內存泄漏、併發與同步的問題。

1.2、性能指標

  • RepsonseTime - RT:響應時間,用戶從客戶端發起一個請求開始計算,到客戶端接收到服務端的響應結束,整個過程所耗費的時間。
  • Hits Per Second - HPS:用戶每秒點擊次數,也就是每秒向後臺發送的請求次數。
  • QPS:系統每秒內處理查詢的次數。
  • MaxRT:最大響應時間,指用戶發出請求到服務端返回響應的最大時間。
  • MiniRT:最少響應時間,指用戶發出請求到服務端返回響應的最少時間。
  • 90%響應時間:將所有用戶的響應時間進行升序排序,取 90 % 的位置。
  • 性能測試關注點:
    • 吞吐量:每秒鐘系統能處理的請求數、任務數。
    • 響應時間:服務處理一個請求或一個任務的耗時。
    • 錯誤率:一批請求中結果出過錯的請求所佔比例。

二、Jmeter 壓測工具

1、Jmeter 工具

  • 下載和安裝 Jmeter 工具

下載地址:

https://jmeter.apache.org/download_jmeter.cgi

我下載的版本是 apache-jmeter-5.3

  • 運行 JMeter 程序

打開批處理文件:\apache-jmeter-5.3\bin\jmeter.bat。如下圖所示:

  • 添加線程組,如下圖所示:
添加線程組
  • 1s 內啓動 200 個線程,循環次數 100 次。2 w 個請求。如下圖所示:
  • 測試 HTTP 請求,如下圖所示:

配置要測試的協議、服務器地址、端口號。配置信息如下:

協議:使用 http 協議。

服務器名稱或 IP: www.baidu.com (只是爲了演示)。

端口號:80 端口。

如下圖所示:

  • 添加查看結果樹、彙總報告和聚合報告。如下圖所示:
  • 開始壓力測試。

    點擊播放按鈕就開始啓動了。注意啓動之前需要先設置線程組的參數配置和 HTTP 請求的配置。如下圖所示:

  • 查看每個請求結果,如下圖所示:
  • 查看彙總報告。

    主要關心平均值和吞吐量。

    200 個線程,每個線程調用 100 次,總共 2 w 次,可以看到下圖中表格中的樣本列也是 2 w,請求所耗費的時間是 151 ms,吞吐量是 880 個請求每秒。如下圖所示:

  • 查看聚合報告。

主要看中位數和90%百分位,

中位數是 59 ms,說明大部分請求的響應時間是 59 ms。

90 % 的請求 都是在 271 ms 以內響應完成的。

異常 0.41% 說明 2 w 個請求中有 82 個請求異常(20000 * 0.0041 = 82 )。

吞吐量 880.2/sec 說明百度這個網站每秒能處理 880 個請求,性能一般(可能跟本地機器性能有關)。

如下圖所示:

  • 查看彙總圖。

查看彙總圖時,需要先勾選想要查看的信息,如下圖所示:

然後查看圖形彙總:

可以看到勾選的幾列在圖表中是用不同顏色表示的,比如綠色的柱狀條就是 90 % 百分位。

我們來測試下 PassJava(佳必過)的管理後臺的性能,吞吐量接近 2000/s。如下圖所示:

三、性能監控之 jconsole

jconsole 和 jvisualvm 是 Java JDK 的兩個小工具,用來監控內存泄漏、跟蹤垃圾回收、執行時的內存情況、對 CPU 進行分析、線程的分析。都可以通過命令行啓動,而且可以監控本地和遠程應用。而 jvisualvm 是升級版的 jconsole。我們先來看下 jconsole 的使用。

首先用 cmd 命令行的方式啓動 jconsole。

啓動 jconsole

命令行啓動 jconsole

選擇監控哪個應用

然後選擇 passjava 項目的 question 服務。

選擇 passjava-question 微服務

對應的就是下面這個微服務:passjava-question。

對應 passjava-question 微服務

概覽

從監控界面上有 6 個菜單,首先看到的是概覽功能,上面有堆內存使用量、線程數、類的使用情況、CPU 佔用率,都是用趨勢圖來表示的,能很方便的看出當前性能的概覽。注意:這些監控都是實時的。

概覽

內存

下面是內存的使用情況,可以從下圖中看到有個下拉框,裏面可以選擇不同的內存維度,然後下面的圖標和柱狀圖也會跟着選擇的維度而展示不同。

內存

下面是線程的使用情況,可以看到線程峯值和活動線程的總數量,目前看到的峯值是59,活動線程數是 57。下半部分可以看到具體是哪些線程,以及線程的堆棧信息,非常詳細。

線程使用情況

下面是類的加載和卸載情況,已加載類總數是 10679,而已卸載的類是 1 個,所以當前已加裝當前類的總數是 10679 - 1 = 10678 個。

類的加載和卸載情況

VM 概要

我們再來看下VM(虛擬機)的情況。如下圖所示,可以看到虛擬機情況,線程、類、堆的概要信息,以及 VM 的參數,是不是很方便呀~

VM 概要

MBean 信息

接下來我們來看下 MBean 信息。對於 MBean,可能很多同學不知道是啥,下面做個解釋:

MBean就是一種規範的JavaBean,通過集成和實現一套標準的Bean接口,這種叫MBean。MBean可以用來幹嘛?就是可以有一套JDK級別的對外的服務接口。比如,你寫了一個JVM允許狀態輔助查詢的Bean,你希望別人下載一個Jconsole就可以看到你寫的傑作。那你就可以考慮用MBean規範來實現。很多垃圾收集器算法Bean就這麼幹的(說的就是這個類sun.management.MemoryImpl)。

MBean 信息

四、性能監控之 jvisualvm

jvisualvm 比 jconsole 更強大,界面展示的信息更豐富。還可以安裝插件,太讚了。

啓動 jvisualvm 和概述

啓動方式和 jconsole 一樣,也是通過 cmd 命令行啓動。還是選擇 passjava-question 微服務,然後選擇第一個菜單欄:概述。可以看到 JVM 的版本,啓動參數等信息。

啓動jvisualvm

監視

監視 CPU、堆、類、線程的情況。整體顯示的效果比 jconsole 更美觀。

監視

線程

再來查下線程的情況。可以看到有 5 種狀態的線程:

  • 運行:正在運行的線程。
  • 休眠:休眠狀態的線程。
  • 等待:等待執行的線程。
  • 駐留:線程裏面的空閒線程。
  • 監視:阻塞的線程,正在等待鎖。

抽樣器

另外我們也可以抽樣器對 CPU 或內存進行抽樣。如下圖所示,對內存進行抽樣。

抽樣

插件的使用

安裝Visual GC 插件

安裝步驟:工具->插件->可用插件->Visual GC->安裝。安裝完成後,重啓就可以使用插件功能了。

安裝完成後,就可以看到

Visual GC 插件

下圖是實時監控垃圾回收的情況。

Visual GC

五、對網關的性能測試

現在我想對 Passjava 系統的 question 微服務的接口進行一個壓測,該如何進行呢?

首先我們來看下 passjava 的架構是怎麼樣的,如下圖所示:

客戶端分爲手機端和 PC 端,http 請求先經過 API Gateway,然後再轉發到 question 微服務。其中涉及到了中間件:Gateway 網關。

我們來對 Gateway 網關進行壓力測試。

網關的端口號是 8060,我們配置下 JMeter。如下圖所示:

配置每秒發送 200 個請求,一直循環執行,直到手動停止壓測。如下圖所示:

可以看下執行結果,吞吐量在 2422 個每秒,還是比較高的。

吞吐量:2422/s 。

90% 響應時間:142 毫秒。

99% 響應時間:281 毫秒。

我們再來看看垃圾回收的情況,Eden 區垃圾回收用時 2.7 s,用時太長了吧,看看這裏怎麼能優化下。

通常的優化方向是增大新生代堆內存配置。

六、對微服務的性能測試

根據上面的架構原理圖,我們知道客戶端請求都是經過 Gateway 轉發了一次的,如果我們想單獨看下微服務的性能該怎麼測試呢?下面我來演示下如何測試 passjava-question 微服務的性能。

首先需要在 passjava-question 微服務中添加一個測試方法:

測試方法

有兩種方式測試這個 api 是否添加正確。

第一種用 postman 測試下這個請求是否能正確響應,返回 “test” 則表示響應正確。

test api 是否能正確響應

第二種通過瀏覽器進行測試。瀏覽器地址欄輸入以下鏈接後,回車,看下瀏覽器窗口是否顯示 “test”,是則表示響應正確。

然後我們需要用 Jmeter 壓測工具來測試這個微服務下的 api 的性能究竟如何。

單獨壓測微服務的 api的結果

吞吐量:3542/s 。

90% 響應時間:100 毫秒。

99% 響應時間:152 毫秒。

七、對網關+微服務的性能測試

如果我們想對這個整個請求鏈路進行性能測試該怎麼做?

首先請求需要先經過網關,然後由網關轉發到微服務。在之前的文章中,我已經將網關配置好了,所以要想通過網關轉發到 test 請求,只需要對請求路徑稍作修改即可,如下所示:

http://localhost:8060/api/question/v1/admin/question/test

然後在瀏覽器輸入該網址,返回 “test” 即表示響應正確。

然後我們還是用 Jmeter 壓測工具測試下 test api 的性能。測試結果如下圖所示:

網關+微服務的壓力測試結果

從結果可以看到:

吞吐量:982/s 。

90% 響應時間:437 毫秒。

99% 響應時間:790毫秒。

這裏做個橫向對比:

橫向對比

說明微服務 api 經過網關轉發一次後,性能至少下降了一半。可以得出結果:中間件越多,性能損失越大,大部分損失都是網絡交互導致的。可以通過增強網絡通信質量來減少網絡的延遲。

八、對數據庫查詢進行優化

一般情況下,出現性能問題更多的是業務中查詢數據庫的耗時。接下來看下如何優化數據的查詢。

下面是一個查詢問題列表的 api:通過問題類型 type 字段過濾問題列表。api 路徑如下:

http://localhost:11000/question/v1/admin/question/list?type=5

這個 api 的代碼如下,很容易看懂。

查詢問題列表的 api

我們加些測試代碼:統計查詢數據庫的耗時。如下所示:

耗時統計

然後重啓 passjava-question 服務,再次測試這個 api,耗時 43 ms

怎麼對查詢進行優化呢?很容易想到加索引,我們來試下加在 question 表加索引後的效果。給 type 字段加上普通索引,如下圖所示:

添加索引

我們再來看下加了索引後的耗時情況:耗時 18 ms,確實比之前的 43 ms 快了很多。

加了索引後的情況

九、優化垃圾回收

我們可以通過 jvisulavm工具查看垃圾回收的情況,Eden 區頻繁發生 GC,短時間(1分鐘)內共造成了 480 次 stop the world。另外從壓測工具中也可以看到,吞吐量爲 275/s。

原因是 Eden 區的內存分配得太小了,只有 32 M,我們來調大一點。

32M Eden 區頻繁進行垃圾回收

增大 Eden 區大小

通過在 IDEA 工具中配置以下參數,調整堆內存最大爲 1024 M,新生代內存爲 512 M。

-Xmx1024m -Xms1024m -Xmn512m

然後可以觀察到在相當長的短時間(1分鐘)內只進行了 92 次垃圾回收,說明垃圾回收的頻率降低了。應用程序的性能也提升了。另外從壓測工具中也可以看到,吞吐量爲 347/s,吞吐量也有較大提升。

十、總結

本文通過壓測工具 Jmeter 講解壓測如何實施,然後用性能監控工具 jconsole 和 jvisualvm 來監控 Java 應用程序的性能,以及如何用工具來優化開源項目 passjava 的性能,並且非常詳細地介紹了每一步以及執行結果,通過對比的方式,更加清晰地知道如何做性能優化。

下面是對系統性能的常規優化手段:

  • 中間件較多時,優化網絡通信質量。

  • 數據庫查詢耗時時,需要對查詢進行優化,比如添加索引。

  • 模板的渲染速度,可以通過設置模板緩存。

  • 靜態資源的獲取,可以通過 Nginx 動靜分離來解決。(下期再講)

  • 日誌太多,需要減少不必要的打 log 操作。

在看點贊轉發,是對我最大的鼓勵。

整理了幾百本各類技術電子書,有需要的同學公號內回覆[ 666 ]自取。技術羣快滿了,想進的同學可以加我好友,和大佬們一起吹吹技術。

你的每個贊和在看,我都喜歡!

本文分享自微信公衆號 - 程序員內點事(chengxy-nds)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

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