效能優化案例之:如何將TPS從60提升到2000?
下面是一個SaaS平臺實際的優化案例,是一個app的登入功能,優化前TPS為十位數,優化之後達到兩千以上。
1. 環境配置
生產環境伺服器配置:
①nginx:2臺4c4g
②api:6臺4c4g
③plat:6臺4c4g
④mysql:3臺8c16g
⑤lvs:2臺4c4g
⑥實名:2臺
壓力機配置:4臺8c16g:
網路頻寬: 內網頻寬萬兆
優化內容: 在壓力機伺服器配置上DNS解析,性有所提高
2. 壓測及優化流程
開發環境壓測跟蹤問題,開發環境壓測TPS 為 67.9
1. 初步發現問題:
JSON例項化導致執行緒Block
解決辦法:
將FastJson替換Jackson
優化結果:
TPS由68TPS升為81TPS,稍有提升
2. 繼續壓測發現大量執行緒被鎖:
KafkaProducer.sendMessage鎖問題
com.systoon.jms.kafka.KafkaProducer.sendMessage
發現是kafa的訊息傳送模式的問題
解決辦法:
將Kafka同步訊息改非同步傳送
增加HttpClient 快取池:
修改前:
修改為:
優化結果:
修改後由81TPS,升為300TPS左右; 提升明顯,直接上升一個檔次.......
3. 調整後上線一次,在生產環境壓測,結果為:
進行400併發tps為165 平均響應時間:2300ms (開發環境與生產環境機器配置及網路環境不同,實際TPS會有一定波動)
經排查,發現問題:
發現JsonPath大量block執行緒
CPU使用率不足3%
就是說CPU遠沒有充分利用,但是TPS已經上不去了
Tomcat日誌響應時間:
Server.xml
從NGINX監控看到的響應時間高達30S:
資料庫SQL響應時間長
併發使用者報錯
解決方案:
引數化資料+墊底資料 , 將FastJson替換JsonPath
原JsonPath處理方式:
修改:FastJson
繼續優化:
再次上線生產環境,壓測,結果:
TPS 由165 直接提升到1300,平均響應時間:2300ms 到300ms
nice ................,但是發現有少量請求提示系統錯誤
4. 繼續排查優化........
優化訊息佇列消費端,以及清除線上kafka堆積訊息,升級jms4.0.4
優化訊息佇列消費端業務程式碼:
消費端減少一次dubbo呼叫和增加快取,
1000併發1000TPS,升為2000TPS
漂亮...............
繼續,優化認證服務的登入邏輯,直接傳入id,減少dubbo呼叫
由 2300TPS,升為2700TPS
but,遇到新問題:
問題分析:
因為共享變數沒有加鎖,在高併發時,傳送訊息出現空指標的問題
解決辦法:
把共享變數修改為區域性變數
修改程式碼優化結果:
ok,搞定,經過一系列的排查和優化措施,登入介面從67TPS 飆升到 2700TPS,可謂提升非常顯著
3. 優化總結
關鍵效能問題如下:
1. DB端:
- SQL索引有無,起效,篩選率低的欄位不需要索引
- select內容
- 讀寫分離
2. 業務優化:
- Log4j2 非同步
- 快取
- 非同步(kafka)
- 簡化業務步驟
- Sleep絕對不允許
- 用空間換時間
- 讀效能遠高於寫
此為一個saas平臺的登入服務介面的優化過程,系統tps與業務複雜度關係密切,優化方式不盡相同,但都有一定共性的方法,要跟蹤整個呼叫鏈條,將各個環節的時間都打出來,定位跟蹤具體時間是卡在什麼環節,然後採取相應措施解決即可。同時儘量簡化業務邏輯,減少呼叫次數,等等......
如果您覺得博主寫的文章對您有幫助,可以請博主喝杯茶哦,O(∩_∩)O~
博主:諸葛本不亮
簡介:畢業後做過多年程式猿、架構設計、專案經理、部門總監,待過傳統軟體公司,也在大型網際網路公司負責過平臺研發部,在這個行業浸淫十多年,在系統架構、SaaS平臺搭建、專案管理以及部門管理等方面有著多年的一線實踐經驗。
目前與好友合夥創辦了一個軟體工作室,提供各類系統解決方案、諮詢服務及技術合作,企業軟體(SaaS平臺、企業應用、商城、微信公眾號及小程式開發)定製開發服務,大資料服務(資料採集及清洗、資料分析等),以及程式猿職業規劃及轉型諮詢服務(程式猿轉架構師、轉專案管理、轉技術管理等,可以提供相應的一線資料幫助您成功轉型,獲得大廠offer)。
微訊號:danwang2138