不久前參與開發了一個基於dubbo分散式框架的底層賬單系統，並實現了其中的一部分業務介面，目前需對這些介面進行壓測，以評估生產環境所能承受的最大吞吐量。筆者以其中一個查詢介面為例來回顧此次壓測的整體流程。 壓測準備： 1.調用查詢介面的測試jar包，作為dubbo-consumer，依賴了查詢服務的 ...
不久前參與開發了一個基於dubbo分散式框架的底層賬單系統，並實現了其中的一部分業務介面，目前需對這些介面進行壓測，以評估生產環境所能承受的最大吞吐量。筆者以其中一個查詢介面為例來回顧此次壓測的整體流程。
壓測準備：
1.調用查詢介面的測試jar包，作為dubbo-consumer，依賴了查詢服務的api，測試module基於maven開發，執行maven clean package即可通過編譯得到jar包
2.JMeter：Apache組織開發的基於Java的壓力測試工具
方案：
無限次請求查詢介面（保證任意時刻併發量相同），觀察Error%為0，當請求平穩進行時的tps，為該介面吞吐量
實施：
1.JMeter中添加一個測試計劃，線程組容量分別設為10、20、50、80、100、200、400、1000、2000，通過jmeter csv data set config設置三組查詢參數
2.準備完畢後，依次在不同容量線程組下啟動測試計劃，結果如下
吞吐量折線統計圖
99%Line折線統計圖
Error%折現統計圖
結論：當線程數為200時，tps達到1700+，隨著線程數增加，99%Line明顯躥升至6s，猜想部分線程請求不到資源，並且Error線程占比瞬間增多也印證了這一點。ps:如果同一組參數測試，壓測效果卻在遞減，可嘗試重啟Jmeter。
思考&決策：
當前測試結構中包含三個節點：本地測試Consumer節點—>查詢介面Provider節點—>資料庫節點，所以相鄰兩個節點間均可能產生併發瓶頸，所以需要定位具體問題發生的具體位置。由於壓測僅需一個節點，所以筆者使用了jVisualVM+jmx+jstacd組合，遠程監聽Dubbo服務所在的那台機器。
調優準備：
1.jstatd：（JDK自帶）基於RMI的服務程式，用於監控基於HotSpot的JVM中資源的創建及銷毀。首次使用需在被監控機器中加入許可權授予文件jstatd.all.policy（jdk的bin目錄下）
文件內容：
grant codebase"file:${java.home}/../lib/tools.jar"{
permission java.security.AllPermission;
};
完畢後執行./jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=遠程伺服器ip &
對外預設開啟1099埠
2.jVisualVM：（JDK自帶）Java性能分析工具
3.jmx：（JDK自帶），是一個為應用程式、設備、系統等植入管理功能的框架，如管理基於tomcat的web服務，本文中管理基於SpringBoot的Dubbo服務，需在啟動腳本中加入jmx的啟動配置
-Dcom.sun.management.jmxremote
-Djava.rmi.server.hostname=遠程伺服器ip
-Dcom.sun.management.jmxremote.port=18999（自定義）
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
方案&實施：
開啟壓測，並觀察jVisualVM中占用CPU時間非常多的熱點方法，並查詢遠程主機cpu使用率情況
jVisualVM觀察面板
發現在正常線程數請求時，獲取DriudDataSource連接池連接的方法CPU時間非常高，經查詢發現，系統中連接池的配置：initialSize、minIdle、maxActive都非常低，遂進行了第一次調優：提升資料庫連接數，連接池初始化連接數50，最小空閑連接數50，最高活躍連接數400。
提升後，獲取連接方法的CPU時間明顯降低，遂測試線程數為400時的請求環境下的支持情況，發現已經開始出現error，即一部分線程請求不到資源，99%Line也達到6s之大！
分析：
此時系統的資料庫連接池配置已經達到400，瓶頸不在此處，那麼會不會是遠程的資料庫節點存在瓶頸，於是遠程登錄資料庫節點，發現mysql的允許連接數非常大，不存在瓶頸。既然請求線程數非常大，資料庫連接池連接數非常大，資料庫提供的連接數也足夠，CPU、JVM均沒有異常，那麼造成性能瓶頸的可能在與dubbo允許提供的連接線程數不足以匹配壓測產生的線程數。
定位到dubbo配置，發現並沒有顯式定義dubbo連接數，查閱dubbo開發文檔
dubbo預設連接線程數
問題發現了：dubbo預設連接線程數為100， 而併發量400的請求線程對dubbo造成的壓力過大，導致壓測不久就出現部分線程請求不到資源超時的問題，遂進行了第二次調優：提升Dubbo線程池連接數，將連接數提升至1000。
那麼是不是到此併發就不存在瓶頸了呢？1000請求線程+dubbo允許線程數1000+資料庫大連接數支持，理論上操作是沒有問題的，我們來實際跑一下，發現壓測時出現了更嚴重的問題，剛開始請求就出現了OOM及超過一半的error線程，準備去遠程機器列印一下執行日誌，就連tail及ps命令都沒有可用資源供執行，停掉了請求線程，又費了九牛二虎之力停掉了服務進程，開始分析原因：各系統間通信均無瓶頸，問題會出在哪裡，是什麼原因撐爆了JVM，已知的條件是遠程服務至少有1000個線程在伺服器內生存，是不是線程量太大撐爆了機器？由於JVM中，棧空間線程私有，查閱JVM參數
JVM線程棧空間
伺服器為linux系統，那預設ThreadStackSize=1024K，那麼1000個線程JVM就需要創建1000*1024k即1個G的空間！這個節點部署三個服務，光一個服務的請求線程就占據1個G，記憶體溢出也是情理之中的了，遂進行了第三次調優：減少線程棧空間，ThreadStackSize調至256K，也是夠用的，再次模擬1000線程併發，OK，無論是系統間線程調用還是記憶體中JVM空間都在正常情況下，並未出現線程請求不到資源的情況。
總結：
本次壓測主要目的是確定單節點在生產環境所能承受的tps峰值，並藉助測試數據反向分析之前開發及單元測試無法覆蓋的隱藏問題，通過三次調優，我們可以發現，該環境下瓶頸主要在系統間請求發生時，以及JVM自身無法負載大數據量線程導致。當然也有可能發生在程式本身過程中，如邏輯中創造大量對象，消耗大量記憶體，或同步邏輯處理塊設計欠缺，導致死鎖、線程餓死等。筆者所描述的問題只是眾多壓測問題中的一小部分，分析、操作難免有疏漏，歡迎各位同學予以指正及建議。感謝華哥、林哥指導，感謝一鳴同學協助~
