業務系統壓測實踐建議（轉）

轉載至：業務系統壓測實踐建議

總原則

• 不管是對HTTP接口、Thrift接口或者Web Service接口進行壓測，發起測試的機器都要儘量靠近被壓測的應用服務器，這樣才能獲得更準確的壓測結果（有效減小網絡傳輸開銷帶來的干擾）

• 排除非業務因素影響：壓測前先確認硬件（CPU、內存、IO、網絡等）、被壓測接口用到的中間件（Tomcat、Nginx、Redis、RabbitMQ等）的配置信息和健康情況。若是存在硬件故障或者中間件故障，則須要先排除掉

• 肯定壓測目標，好比是壓測tps、內存消耗量仍是其餘如要能支持多少併發用戶，達到多少tps

• 肯定一個壓測基準，好比壓測某個HTTP API接口的tps時，能夠先壓測心跳檢測接口（業務邏輯最少），好比壓測獲得5000tps，那麼就能夠判定其餘業務邏輯更復雜的HTTP API接口的極限tps不可能超過5000tps，不管你怎麼優化（這裏的優化特指業務性能優化，若是中間件優化了，則須要從新肯定壓測基準）

• 壓測前最好用ping、traceroute查看下網絡連通情況

• 通常先對單臺服務器作壓測，單臺服務器壓測達到指望的壓測指標後再擴展到集羣環境對多臺服務器作壓測

• 壓測服務器儘量和線上服務器一致或者相似，確認發起測試的服務器自己不存在性能瓶頸（好比還沒開始壓測，發起測試的機器CPU就已經100%、測試機器在建立多一些線程的時候CPU增加很快）

• 儘量複製或者模擬真實流量來作壓測。好比在壓測HTTP API接口時，若是後端作了Cache，通常第一次請求會Cache Miss，但後續請求都會Cache Hit，因此重複請求同一個url來壓測可能會獲得錯誤的「樂觀結果」。推薦用tcpcopy來複制線上真實流量（tcpcopy）

• 壓測時先用少許併發用戶、少許總請求數，而後逐漸增大併發用戶數、總請求數。同時查看系統業務日誌、系統負載狀況（top）、系統資源消耗變化狀況（vmstat）、GC狀況和出錯率等

• 壓測時間儘量越長越好，以便觀察系統在一段較長時間內的穩定性（之前遇到過系統固定跑一天就崩潰的狀況）

• 壓測HTTP接口時，須要確認Nginx是否開啓gzip壓縮（若是響應數據包挺大時開啓gzip壓縮與否對結果影響挺大）、KeepAlive開啓狀態、HTTP Cache開啓狀態等

• 壓測時獲取到的應用內部運行信息越詳細越好，好比Tomcat鏈接池、Thrift客戶端鏈接池、Thfift服務端鏈接池的運行狀態，一個請求各環節的執行時間（日誌埋點）

• 壓測前須要想清楚整個系統從前到後的拓撲結構圖，能夠在紙上畫下來

• 若是應用自己每次請求都會調用第三方服務接口，那麼先對第三方服務接口作壓測，先確認第三方服務接口不存在性能問題

壓測流程

1. 檢查硬件和中間件配置信息和運行健康情況，好比Tomcat最大鏈接數設置是否合理、Nginx配置是否合理等，確保它們不會影響壓測結果

2. 肯定壓測目標，好比「壓測某HTTP接口的極限，要求1000併發用戶下單臺tomcat能達到5000tps」

3. 部署應用到壓測服務器，準備好發起測試的服務器（若是能和壓測服務器同樣最好，不能同樣至少也要作到在同一個局域網內），而後用ping、traceroute查看下網絡連通情況

4. 肯定壓測基準，好比獲取心跳檢測請求的極限tps

5. 構造儘量接近真實用戶訪問狀況的測試數據，好比用tcpcopy複製線上真實流量

6. 逐漸增大併發量和總請求數，觀察系統層面的各項 指標和應用運行情況，採用的工具通常是ab、jmeter、loadrunner等

7. 有時候可能須要長時間讓系統高負載運行，好比觀察系統長時間處於高負載狀況下是否會出現GC故障

一些經驗教訓

1. 不要迷信「推薦配置」，須要根據實際狀況調整配置。好比如今咱們Thrift服務的selector線程數推薦值爲2，worker線程數推薦值爲10，然而對平均執行時間10ms左右的Thrift接口作壓測時發現大量請求被阻塞，而當調整selector線程數爲20、worker線程數爲100後發現阻塞狀況顯著減輕

2. 壓測時一切判斷必須基於真實測量數據，不能想固然。好比認爲某個環節的邏輯不多，而後武斷地認爲性能瓶頸確定不會出在那個環節，而後就忽略測量這個環節的耗時

3. 可能不止一個環節存在性能瓶頸，好比某個請求會流經A => B => C => D四個環節，通過測量發現當前性能瓶頸存在於B環節（好比80%的時間都消耗在B環節），而後通過努力終於把環節B的耗時降下來了，也許你會發現吞吐量和平均響應時間仍是上不去而且再測量後發現如今性能瓶頸又變成C了。緣由是：實際上B和C兩個環節都存在性能問題，只不過未對B環節調優以前，大部分請求流量都堵塞在B環節，致使到達C環節的請求流量壓力很是小，因此C環節的性能問題也就凸顯不出來了；而當排除B環節的性能問題後，C環節單位時間內接收到的流量劇增，天然而然C環節的性能問題就暴露出來了。也正所以，對於複雜的業務流程，壓力測試很難作到一蹴而就，須要逐一排查突破

4. 儘量自動化獲取各個環節的性能數據。若是能經過一個集成的監控系統直觀地觀察到各個環節的耗時，那麼對於診斷整個系統的性能瓶頸將很是有幫助（當你嘗試過手動插入執行時間記錄日誌並收集分析後就能切身體會這點了）。同時監控系統也將爲提高系統穩定性和可用性提供一大保障

5. 即便你依賴的一個服務號稱能達到tps多少多少，號稱性能有多快多快，也有必要先弄清楚它的壓測場景（用多少數據測的、併發用戶多少、總請求多少、測試請求數據是什麼樣的、可否復現）。確認沒問題後還要再檢查本身的壓測設置有沒有問題，好比一個高性能HTTP接口也可能由於你的網絡環境或者HTTP客戶端鏈接池大小設置不當、超時時間設置不當等緣由而測不出你預期的性能

6. 高併發場景若是使用log4j（假如採用默認配置）打印大量日誌，會對系統吞吐量形成巨大影響，由於默認log4j寫日誌是同步寫，多線程併發寫日誌時會等待一個同步鎖，以下：

/*
 * org.apache.log4j.Category.callAppenders
 */
public void callAppenders(LoggingEvent event) {
   int writes = 0;
   for(Category c = this; c != null; c=c.parent) {
   // Protected against simultaneous call to addAppender, removeAppender,...
   synchronized(c) {
      if(c.aai != null) {
         writes += c.aai.appendLoopOnAppenders(event);
      }
      if(!c.additive) {
	 break;
      }
   }
}

    if(writes == 0) {
      repository.emitNoAppenderWarning(this);
    }
  }

推薦使用logback替換log4j，或者採用異步寫日誌並調大log buffer size