性能與壓力測試
文章目錄
性能與壓力測試
一、性能監控
1、jvm記憶體模型
2、堆
3、jconsole與jvisualvm
1、jvisualvm能幹什麼
2、安裝插件友善檢視 GC
4、監控名額
1、中間件名額
2、資料庫名額
5、 JVM 分析&調優
1、幾個常用工具
2、指令示例
3、調優項
1、性能壓測-優化-nginx動靜分離
2、性能壓測-優化-模拟線上應用記憶體崩潰當機情況
1、JVM調優-設定商品服務啟動參數進行比較，都以50個線程為例：
2、模拟線上應用記憶體崩潰當機情況
3、性能壓測-優化-優化三級分類資料擷取
二、壓力測試
1、性能名額
2、JMeter
1、JMeter安裝
2、JMeter壓測示例
3、JMeter Address Already in use 錯誤解決
一、性能監控
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：
監控記憶體洩露，跟蹤垃圾回收，執行時記憶體、cpu分析：
線程分析：
運作: 正在運作的
休眠: sleep
等待: wait
駐留: 線程池裡面的空閑線程
監視: 阻塞的線程，正在等待鎖
2、安裝插件友善檢視 GC
cmd啟動 jvisualvm
工具→插件
如果503錯誤解決:
打開網址 https://visualvm.github.io/pluginscenters.html
cmd 檢視自己的 jdk 版本,找到對應的
安裝完插件需要重新開機 jvisualvm
4、監控名額
開發環境配置：
實體機： 開發和服務運作
虛拟機： 運作中間件和資料庫，記憶體3G，1核
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：
結果彙總：
壓測内容
壓測線程數
吞吐量/s
90%響應時間
99%響應時間
Nginx
50
6564
4ms
172ms
Gateway
50
12356
6
19
簡單服務
50
14177
4
65
首頁一級菜單渲染(未開thymeleaf緩存)
50
515
130
200
首頁一級菜單渲染(開啟thymeleaf緩存、優化資料庫、關日志)
50
607/700
101/86
118/151
三級分類資料擷取
50
5/19(加索引)
11141/2764
11366/2956
三級分類資料擷取(業務邏輯優化)
50
200
398
644
三級分類資料擷取(使用redis緩存)
50
684
95
128
首頁全量資料擷取(優化前/優化後/動靜分離後)
50
20/22/550
3426/2522/103
4272/3133/804
Nginx+Gateway
50
Gateway+簡單服務
50
4919
21
47
全鍊路
50
1439
50
80
簡單服務：慢的原因，一是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：
css：
img：
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