下面是一個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