性能與壓力測試

@[toc]

一、性能監控

1、jvm內存模型

• 程序計數器 Program Counter Register：

  • 記錄的是正在執行的虛擬機字節碼指令的地址

  • 此內存區域是唯一一個在JAVA虛擬機規范中沒有規定任何OutOfMemoryError的區域

• 虛擬機棧 VMStack：

2、堆

所有的對象實例以及數組都要在堆上分配。堆是垃圾收集器管理的主要區域，也被稱為"GC堆”;也是我們優化最多考慮的地方。堆可以細分為：

• 新生代
  • Eden空間
  • From Survivor空間
  • To Survivor空間
• 老年代
• 永久代/元空間
  • Java8以前永久代，受jvm管理， java8以后元空間，直接使用物理內存。因此，默認情況下，元空間的大小僅受本地內存限制。

垃圾回收

從Java8開始， Hotspot已經完全將永久代(Permanent Generation)移除，取而代之的是個新的區域一元空間(MetaSpace)

3、jconsole與jvisualvm

JDK 的兩個小工具 jconsole、jvisualvm(升級版的jconsole) ;通過命令行啟動，可監控本地和遠程應用。遠程應用需要配置

jconsole：

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

1、jvisualvm能干什么

監控內存泄露，跟蹤垃圾回收，執行時內存、cpu分析，線程分析

啟動jvisualvm：

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

線程分析：

在這里插入圖片描述

• 運行: 正在運行的
• 休眠: sleep
• 等待: wait
• 駐留: 線程池里面的空閑線程
• 監視: 阻塞的線程，正在等待鎖

2、安裝插件方便查看 GC

• cmd啟動 jvisualvm
• 工具→插件
  
  在這里插入圖片描述
• 如果503錯誤解決:
  • 打開網址 https://visualvm.github.io/pluginscenters.html

  • cmd 查看自己的 jdk 版本,找到對應的

    
    
    在這里插入圖片描述

在這里插入圖片描述

安裝完插件需要重啟 jvisualvm

`在這里插入圖片描述`

4、監控指標

開發環境配置：

實體機： 開發和服務運行

在這里插入圖片描述

CentOS-7、Docker、redis、mysql:5.7、elasticsearch:7.4.2、kibana:7.4.2、nginx:1.10

1、中間件指標

nginx：

• 計算型

• 消耗cpu

  
  
  在這里插入圖片描述
  
  
  在這里插入圖片描述
  
  
  在這里插入圖片描述

Gateway：

• 計算型

• 比較消耗cpu

  
  
  在這里插入圖片描述
  
  
  在這里插入圖片描述
  
  
  在這里插入圖片描述
  
  
  在這里插入圖片描述

2、數據庫指標

• SQL耗時越小越好，一般情況下微秒級別。
• 命中率越高越好，一般情況下不能低于95%
• 鎖等待次數越低越好，等待時間越短越好。

服務壓測：

簡單服務(不請求數據庫)：

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

Gateway+簡單服務(不請求數據庫)：

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

全鏈路(不請求數據庫)：

在這里插入圖片描述

在這里插入圖片描述

首頁一級菜單渲染(不過網關)：

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

三級分類數據獲取：

在這里插入圖片描述

在這里插入圖片描述

首頁全量數據獲取：

在這里插入圖片描述

在這里插入圖片描述

在這里插入圖片描述

Nginx+Gateway：

結果匯總：

簡單服務：慢的原因，一是DB，二是thymeleaf渲染。通過對比可以看到：

• 首頁一級菜單渲染在開啟thymeleaf緩存前后吞吐性能提升約17.86%，還是比較明顯的。
• 首頁一級菜單渲染訪問的時候，在關閉debug日志和給where條件列加索引之后，DB請求耗時從原來的6-1085ms，提升至2-8ms，速度提升3-135倍。
• 首頁一級菜單渲染在開啟thymeleaf緩存、優化數據庫（加索引）、關日志之前和之后的對比可以看到吞吐量提升約35.92%。

三級分類數據獲取：慢的原因，主要是DB，存在遍歷查詢，多次請求服務的過程，數據庫IO頻繁，開發環境未關閉debug級別的日志；目前服務尚未使用數據庫連接池，可配置數據庫連接池進行優化，另外對于三級分類這種不會經常變動的數據，可以選擇使用redis緩存起來來提高訪問的效率。

首頁全量數據獲取：慢的原因，通過和首頁一級菜單渲染進行對比可以知道，慢的原因主要是靜態資源加載慢；目前我們的服務尚未做動靜資源的請求分離操作，可以使用nginx做靜態資源服務器來進行優化。

結論及優化：

• 中間件越多，性能損失越大，大多都損失在網絡交互。可以優化中間件配置，使用更快的硬件資源
• 業務：
  • DB（MySQL服務優化，索引優化）
  • 模板的渲染速度（thymeleaf開發期間是關閉緩存的，服務上線后要開啟緩存；模板渲染需要CPU去計算，所以可以使用更好的CPU；服務器內存）
  • 靜態資源

5、 JVM 分析&調優

1、幾個常用工具

2、命令示例

3、調優項

1、性能壓測-優化-nginx動靜分離

在這里插入圖片描述

1）上傳靜態資源到nginx服務器

• 在/mydata/nginx/html/路徑下創建static/文件夾
• 將本地代碼路徑中的src\main\resources\static文件夾下的靜態資源文件全部上傳到nginx服務器中。

2）修改nginx配置文件并重啟

• 修改從nginx的conf.d目錄中的 default.conf 文件復制的 pafcmall.conf文件，在 location / { 之前添加靜態資源文件訪問路徑配置：

# 配置靜態資源訪問路徑 
location /static/ {
    root   /usr/share/nginx/html;
}  

• 重啟nginx：docker restart nginx

3）修改本地代碼，刪除本地代碼路徑中的src\main\resources\static文件夾下的靜態資源文件，同時修改index.html文件中對靜態資源的引用路徑。

• js：

<script src="/static/index/js/xxx.js" type="text/javascript" charset="utf-8"></script>

• css：

<link rel="stylesheet" href="/static/index/css/xxx.css">

• img：

<img src="/static/index/img/xxx.jpg" />

2、性能壓測-優化-模擬線上應用內存崩潰宕機情況

1、JVM調優-設置商品服務啟動參數進行比較，都以50個線程為例：

1）-Xmx100m

在這里插入圖片描述

在這里插入圖片描述

2）-Xmx512m

設置堆內存最大大小為512m

在這里插入圖片描述

在這里插入圖片描述

3）-Xmx1024m -Xms1024m -Xmn512m

設置堆內存最大和最小大小為1024m；并設置新生代（Eden+S0+S1）為512m，減少垃圾回收器進行頻繁的Minor GC

在這里插入圖片描述

在這里插入圖片描述

2、模擬線上應用內存崩潰宕機情況

將jmeter的線程數設置到200，將服務的最大堆內存設置到-Xmx100m，進行模擬測試：
服務不可用：

在這里插入圖片描述

OOM異常：

在這里插入圖片描述

3、性能壓測-優化-優化三級分類數據獲取

將數據庫多次查詢變為一次查詢，減少數據庫頻繁IO，可以看到50個線程，Xmx為100m的情況下，服務的吞吐量達到了200，相比之前圖標中只加索引的19，性能提升約10倍。

在這里插入圖片描述

如果還想要進一步提升性能，就需要考慮使用數據庫連接池、使用緩存的情況，這個會在后面介紹到。

二、壓力測試

壓力測試：

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

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

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

1、性能指標

• 響應時間(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-1000000TPS

  互聯網中型網站: 1000TPS-50000TPS

  互聯網小型網站: 500TPSM10000TPS

• 最大響應時間(Max Response Time)：指用戶發出請求或者指令到系統做出反應(響應)的最大時間。

• 最少響應時間(Mninum ResponseTime)：指用戶發出請求或者指令到系統做出反應(響應）的最少時間。90%響應時間(90% Response Time)是指所有用戶的響應時間進行排序,第90%的響應時間。

• 從外部看,性能測試主要關注如下三個指標：

  吞吐量:每秒鐘系統能夠處理的請求數、任務數。

  響應時間:服務處理一個請求或一個任務的耗時。

  錯誤率:一批請求中結果出錯的請求所占比例。

2、JMeter

1、JMeter安裝

https://jmeter.apache.org/download_jmeter.cgi 下載對應的壓縮包,解壓運行 jmeter.bat 即可

2、JMeter壓測示例

添加線程組——添加請求數：

在這里插入圖片描述

在這里插入圖片描述

添加取樣器——添加請求接口：

在這里插入圖片描述

[

添加監聽器——觀察執行結果：

在這里插入圖片描述

在這里插入圖片描述

3、JMeter Address Already in use 錯誤解決

windows 本身提供的端口訪問機制的問題。

Windows提供給TCP/IP鏈接的端口為 1024-5000,并且要四分鐘來循環回收他們。就導致我們在短時間內跑大量的請求時將端口占滿了。

1.cmd 中,用 regedit 命令打開注冊表

2.在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 下

1,右擊 parameters,添加一個新的 DWORD,名字為 MaxUserPor

2.然后雙擊 MaxUserPort,輸入數值數據為 65534,基數選擇十進制(如果是分布式運行的話,控制機器和負載機器都需要這樣操作哦)

3,修改配置完畢之后記得重啟機器才會生效

https://support.microsoft.com/zh-cn/help/196271/when-you-try-to-connect-from-tcp-ports-greater-than-5000-you-receive-t

TCPTimedWaitDelay: 30