? ? ? ?不久前參與開發了一個基于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.準備完畢后，依次在不同容量線程組下啟動測試計劃，結果如下
? ? ? ?結論：當線程數為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使用率情況
? ? ? ?發現在正常線程數請求時，獲取DriudDataSource連接池連接的方法CPU時間非常高，經查詢發現，系統中連接池的配置：initialSize、minIdle、maxActive都非常低，遂進行了第一次調優：提升數據庫連接數，連接池初始化連接數50，最小空閑連接數50，最高活躍連接數400。
? ? ? ?提升后，獲取連接方法的CPU時間明顯降低，遂測試線程數為400時的請求環境下的支持情況，發現已經開始出現error，即一部分線程請求不到資源，99%Line也達到6s之大！
分析：
? ? ? ?此時系統的數據庫連接池配置已經達到400，瓶頸不在此處，那么會不會是遠程的數據庫節點存在瓶頸，于是遠程登錄數據庫節點，發現mysql的允許連接數非常大，不存在瓶頸。既然請求線程數非常大，數據庫連接池連接數非常大，數據庫提供的連接數也足夠，CPU、JVM均沒有異常，那么造成性能瓶頸的可能在與dubbo允許提供的連接線程數不足以匹配壓測產生的線程數。
? ? ? ?定位到dubbo配置，發現并沒有顯式定義dubbo連接數，查閱dubbo開發文檔
? ? ? ?問題發現了：dubbo默認連接線程數為100， ?而并發量400的請求線程對dubbo造成的壓力過大，導致壓測不久就出現部分線程請求不到資源超時的問題，遂進行了第二次調優：提升Dubbo線程池連接數，將連接數提升至1000。
? ? ? ? 那么是不是到此并發就不存在瓶頸了呢？1000請求線程+dubbo允許線程數1000+數據庫大連接數支持，理論上操作是沒有問題的，我們來實際跑一下，發現壓測時出現了更嚴重的問題，剛開始請求就出現了OOM及超過一半的error線程，準備去遠程機器打印一下執行日志，就連tail及ps命令都沒有可用資源供執行，停掉了請求線程，又費了九牛二虎之力停掉了服務進程，開始分析原因：各系統間通信均無瓶頸，問題會出在哪里，是什么原因撐爆了JVM，已知的條件是遠程服務至少有1000個線程在服務器內生存，是不是線程量太大撐爆了機器？由于JVM中，?？臻g線程私有，查閱JVM參數
服務器為linux系統，那默認ThreadStackSize=1024K，那么1000個線程JVM就需要創建1000*1024k即1個G的空間！這個節點部署三個服務，光一個服務的請求線程就占據1個G，內存溢出也是情理之中的了，遂進行了第三次調優：減少線程?？臻g，ThreadStackSize調至256K，也是夠用的，再次模擬1000線程并發，OK，無論是系統間線程調用還是內存中JVM空間都在正常情況下，并未出現線程請求不到資源的情況。
總結：
? ? ? ?本次壓測主要目的是確定單節點在生產環境所能承受的tps峰值，并借助測試數據反向分析之前開發及單元測試無法覆蓋的隱藏問題，通過三次調優，我們可以發現，該環境下瓶頸主要在系統間請求發生時，以及JVM自身無法負載大數據量線程導致。當然也有可能發生在程序本身過程中，如邏輯中創造大量對象，消耗大量內存，或同步邏輯處理塊設計欠缺，導致死鎖、線程餓死等。筆者所描述的問題只是眾多壓測問題中的一小部分，分析、操作難免有疏漏，歡迎各位同學予以指正及建議。感謝華哥、林哥指導，感謝一鳴同學協助~
