1. 程式人生 > >效能優化案例之:如何將TPS從60提升到2000?

效能優化案例之:如何將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