分散式高階篇(二) - 壓測與效能監控
分散式高階篇(二) - 壓測與效能監控
效能壓測與優化
壓力測試
- 壓力測試考察當前軟硬體環境下系統所能承受的最大負荷並幫助找出系統瓶頸所在。壓測都是為了系統在線上的處理能力和穩定性維持在一個標準範圍內，做到心中有數
- 使用壓力測試，我們有希望找到很多種其他測試方法更難發現的錯誤。有兩種錯誤型別是：記憶體洩露、併發與同步
- 有效的壓力測試系統將應用以下這些關鍵條件：重複、併發、量級、隨機變化
效能指標
-
響應時間（Respone 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
- 網際網路小型網站：500TPS~10000TPS
-
最大響應時間（Max Response Time）：指使用者發出請求或者指令到系統做出的反應（響應）的最大時間
-
最小響應時間（Mininum Response Time）: 指使用者發出請求或者指令到系統做出反應（響應）的最小時間
-
90%響應時間（90% Response Time）：是指所有使用者的響應時間進行排序，第90%的響應時間
-
從外部看，效能測試主要關注如下三個指標
- 吞吐量：每秒鐘系統能夠處理的請求數、任務數
- 響應時間：服務處理一個請求或一個任務的耗時
- 錯誤率：一批請求中結果出錯的請求所佔比例
壓測工具JMeter
下載安裝JMeter
-
下載地址
JMeter 使用
-
解壓
-
進入bin目錄，執行
jmeter.bat
JMeter 壓測示例
-
1：新增執行緒組（新增--執行緒（使用者）--執行緒組）
右擊TestPlan
-
執行緒屬性
- 執行緒數：模擬多少個使用者同時訪問
- Ranp-Up時間（秒）：多少秒內完成上面設定的執行緒數。例如：10秒 200執行緒數 ：代表沒秒20個請求
- 迴圈次數：代表每個執行緒迴圈的次數 例如迴圈次數=100，每個執行緒請求執行100次，200個執行緒就是20000次
-
2：HTTP請求（新增--取樣器--HTTP請求）
指定請求介面，埠和請求所需的引數
-
3：檢視百度的測試結果（新增--監聽器--檢視結果樹/彙總報告/聚合報告）
JMeter Address Already in use 錯誤解決
-
windows本身提供的埠訪問機制問題。
-
Windows提供給TCP/IP連結的埠為1024-5000，並且要四分鐘來迴圈回收他們，就導致我們在短時間內跑大量的請求時將端口占滿了
-
解決方式
-
1、cmd中，用regedit命令開啟登錄檔
-
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
-
影響效能考慮點
- 資料庫、應用程式、中介軟體（tomcat、nginx）、網路和作業系統等
- 首先要考慮自己的應用屬於CPU密集型還是IO密集型
效能監控
JVM記憶體模型
-
JVM記憶體模型
-
程式計數器（Program Counter Register）
- 記錄的是正在執行的虛擬機器位元組碼指令的地址
- 此記憶體區域是唯一一個在JAVA虛擬機器規範中沒有規定任何OutOfMemoryError的區域
-
‘虛擬機器：VM Stack
- 描述的是JAVA方法執行的記憶體模型，每個方法在執行的時候都會建立一個棧幀，用於儲存區域性變量表，運算元棧，動態連結，方法介面等資訊
- 區域性變量表儲存了編譯器可知的各種基本資料型別、物件引用
- 執行緒請求的棧深度不夠會報StackOverFlowError異常
- 棧動態擴充套件的容量不夠會報OutOfMemoryError異常
- 虛擬機器棧是執行緒隔離的，即每個執行緒都有自己獨立的虛擬機器棧
-
本地方法：Native Stack
- 本地方法棧類似於虛擬機器棧，只不過本地方法棧使用的是本地方法
-
堆：Heap
- 幾乎所有的物件例項都在堆上分配記憶體
堆
-
所有的物件例項以及陣列都要在堆上分配。堆是垃圾回收器管理的主要區域，也被稱為“GC堆”；也是我們優化最多考慮的地方
堆可以細分為：
- 新生代
- Eden空間 （伊甸園區）
- FromSurvivor 空間 （倖存0區）
- ToSurvivor 空間 （倖存1區）
- 老年代
- 永久代/元空間
- java8以前永久代，受JVM 管理，java8以後元空間，直接使用實體記憶體。因此，預設情況下，元空間的大小僅受本地記憶體限制
- 新生代
-
垃圾回收
垃圾回收流程圖
jconsole與jvisualvm
- jdk的兩個小工具jconsole、jvisualvm（升級版的jconsole）；通過命令列啟動，可監控本地和遠端應用。遠端應用需要配置
jvisualvm
-
監控記憶體洩露，跟蹤垃圾回收，執行時記憶體、CPU分析，執行緒分析...
-
cmd 啟動 jvisualvm
執行：正在執行的執行緒
休眠：sleep
等待：wait
駐留：執行緒池裡的空閒執行緒
監視：阻塞的執行緒，正在等待鎖
安裝外掛方便檢視gc
-
工具---外掛安裝---visual gc（安裝完成，重啟
jvisualvm）
監控指標
中介軟體指標
-
監控nginx
-
docker stats 檢視容器資源佔用
-
jmeter 壓測 nginx （192.168.83.133:80/） 50個執行緒 一直迴圈
觀察發現nginx主要是佔用cpu，記憶體變化不大
-
-
監控閘道器
-
jmeter 壓測 GateWay（localhost:9527/） 50個執行緒 一直迴圈
也是主要佔用CPU，但是Eden區
gc特別頻繁，可以修改這塊來提高吞吐量
-
-
壓測首頁全量資料
-
包括html、js、css等靜態資源
-
資料庫指標
優化-nginx動靜分離
-
由於動態資源和靜態資源目前都處於服務端，所以為了減輕伺服器壓力，我們將js、css、img等靜態資源放置在Nginx端，以減輕伺服器壓力
-
將專案static目錄下的 index 複製到
nginx的掛載檔案/html/static目錄下-
修改
conf/conf.d/目錄下的mall.conf#新增 location /static/ { root /usr/share/nginx/html/; }
-
壓測報表（*）
-
對不同內容壓測的資料統計
壓測內容 壓測執行緒數 吞吐量/s 90%響應時間/ms 99%響應時間/ms Nginx 50 6721 14 22 GateWay 50 16211 5 16 簡單服務
localhost:12000/hello50 24715 3 8 GateWay+簡單服務
localhost:9527/hello50 6300 15 76 Nginx+GateWay+簡單服務(全鏈路)
mall.com/hello50 120 1644 2453 首頁一級選單渲染
localhost:12000/50 445(db,thymeleaf) 163 248 首頁一級選單渲染(thymeleaf開啟快取)
localhost:12000/50 528(db) 143 227 首頁一級選單渲染(開快取&優化資料庫(加索引)&關日誌)
localhost:12000/50 1244 66 116 三級分類資料獲取
localhost:12000/index/catalog.json50 3.8(db導致) 13205 13519 三級分類資料獲取(多次查庫變一次查庫)
localhost:12000/index/catalog.json50 218 330 536 三級分類資料獲取(加索引)
localhost:12000/index/catalog.json50 16.7 3314 3554 首頁全量資料獲取
localhost:12000/50 7(靜態資源) 6603 6740 首頁全量資料獲取(動靜分離)
localhost:12000/50 36.3 1565 2018 -
測試結論：
- 中介軟體越多，效能損失越大，大多數都損失在網路互動中
- 業務：
- DB（MySQL優化：伺服器、索引...）
- 模板的渲染速度（快取）
- 靜態資源（動靜分離）
- gc記憶體分配不合理
優化三級分類資料獲取
-
之前版本，巢狀迴圈查詢資料庫
-
優化思路
-
1、將資料庫的多次查詢變為一次
com.touch.air.mall.product.service.impl.CategoryServiceImpl.getCatalogJson
-