談談性能基線

1、背景與說明

1.一、性能基線的背景與意義

  當系統的操做響應時間超出了用戶可接受的程度，說明系統出現了性能問題，須要技術人員對系統進行優化，可是 「用戶是否可接受」是一個主觀的沒法直接測量的標準，具體在何種程度下須要開啓對系統性能的優化工做，又優化到何種程度後能夠終止工做，沒有統一的度量標準。 
  另外，真正引發性能問題的緣由不只僅是程序代碼，也多是承載系統運行的計算資源不充足，那麼如何讓性能優化人員明確目前究竟是應該擴充計算資源仍是修改程序代碼，也須要有統一的指導標準和原則。 
  在這些問題背景下，性能基線就顯得十分必要。性能基線的含義就是在可控的標準化的環境下，經過測試工具採集和人工分析後得出的有參考價值的指標數據。歸納的來講，這些指標數據的主要做用以下： 
  1.爲容量規劃肯定系統和應用程序的極限； 
  2.爲配置測試的參數和配置選項提供參考依據； 
  3.爲驗收測試肯定系統是否具有本身所宣稱的能力； 
  4.爲性能基線的創建提供長期的數據統計來源以及比較基準。

1.二、預期讀者與目標

  系統架構師或技術負責人：依照系統性能需求，參照性能基線測算計算資源需求； 
  性能測試人員：瞭解性能基線指標值，可以在測試環境中計算資源不充足的狀況下，也對系統的性能表現進行測試並把關，明確系統性能是否達到基線要求，性能測試是否能夠經過； 
  性能調優人員：爲性能調優創建目標，只有系統性能表現知足基線指標值，方可完成性能調優工做。

1.三、性能基線指標選擇

1.3.一、性能指標相關名詞解釋

  QPS：每秒請求處理量(Query Per Second)，是對一個特定的應用系統在規定時間內所處理流量多少的衡量標準。通俗講即，每秒鐘處理完請求的次數，注意這裏是處理完，具體是指發出請求到服務器處理完成功返回結果； 
  事務（Transaction）：一組請求，事務的開始和事務的結束在錄製壓測腳本時定義，事務中包含的請求視具體業務場景而定，故事務中請求的數量沒法固定有多有少。例如：用戶登陸做爲一個事務，裏面包含了登陸頁面加載、登陸驗證請求、首頁面菜單數據請求、消息提醒請求、元件頁面加載請求等多個服務器請求； 
  併發：系統能同時處理的事務數，在loadrunner壓測工具裏，併發通常指設置的併發用戶數Vuser的數量； 
  TPS：Transaction Per Second，每秒鐘系統可執行完成的事務的數量。 
  併發、QPS、TPS間的關係： 
    QPS = TPS*事務包含請求數量 
    併發數 = (QPS/事務包含請求數量)*事務平均響應時間 
    併發數 = TPS*事務平均響應時間

1.3.二、基線指標選擇

1、爲何不使用併發做爲性能基線指標？ 
  在脫離了響應時間標準的狀況下，單純的併發量，只能反映系統承載壓力，不能反映系統的性能表現，固只用併發來做爲性能基線指標沒有意義。

2、爲何不使用併發+響應時間（即TPS）做爲性能基線指標？ 
  項目上的性能需求描述每每是支持多少併發，響應時間在多少秒之內，這個完整的描述實際上就是TPS的要求。例如：500併發用戶，響應時間不超過3秒，依照上文併發與TPS的換算公式，TPS指標要求極爲500/3=166.6，即應用系統須要單秒處理166筆事務。 
  按上述，TPS確實能夠反映出系統的性能表現，但考慮事務的多樣性複雜性，TPS數值沒有普適價值。壓測TPS值會被測試場景事務的複雜度影響，實際舉例： 
  有A、B兩套系統，使用相同的硬件資源進行部署，A系統登陸場景下，內部由10個請求構成，B系統登陸場景，內部由15個請求構成，A系統壓測結果有150TPS，B系統壓測結果有100TPS，雖然A系統TPS值更高，但並不能說明A系統的性能表現比B系統好，由於B系統自己根據業務須要，場景複雜度更高，單事務對系統資源的需求也更高，TPS值比A系統低是合理的，故TPS也不能用來做爲性能極限指標。

3、爲何要使用QPS做爲性能基線指標？ 
  請求做爲構成服務器壓力的原子單位，單位時間內處理請求數（QPS）相較上述指標來講，更易做爲跨系統、不一樣硬件環境下性能對比的統一標準。 
  仍是上述A、B系統爲例，A系統場景10個請求，150TPS，換算爲QPS爲1500，B系統場景15個請求，100TPS，換算爲QPS也是1500，雖然到請求級別，也會存在複雜度誤差，但基於統計與比較基準須要，能夠認爲A、B兩套系統的性能表現持平或者是接近，並不是A系統表現比B好不少。

4、還須要加入硬件資源的考量因素 
  上述A、B系統，假設前提是使用了相同的硬件資源條件，可是在實際狀況下，不一樣系統部署使用的硬件資源是不同的，若是A系統使用了更好的資源，性能表現優於B系統，也沒法說明A系統的程序性能優於B系統。 
  故性能基線除了QPS值之外，還須要加入硬件資源的考量因素，最終性能基線的指標爲：單位硬件資源（如單臺應用服務器4核8G內存）下，系統壓測的QPS極值。

2、性能基線測試

2.一、測試目的與策略

  基線測試的目的是獲得壓測基礎數據，便於後續推導出性能基線指標。 
  主要的測試策略： 
    1.構建可控環境，提供標準化的測試場景、測試工具和測試環境資源； 
    2.使用壓測工具，測試同一場景，經過不斷改變硬件資源投入，分別得到系統QPS極值。

2.二、測試準備

2.2.一、測試場景標準化

場景1、讀數據場景 
  腳本概述：訪問用戶登陸頁，輸入帳戶密碼後，等待加載首頁完，在我的消息中內心進行搜索(搜索條件爲空) ，腳本中帳戶密碼參數化500個帳號。實際包含對一張數據量100萬級別的數據表進行2次數據庫查詢操做。 
  壓測場景：沒有集合點和思考時間，模擬緩存壓測，500併發

場景2、寫數據場景 
  腳本概述：訪問用戶登陸頁，輸入帳戶密碼後，等待加載首頁完，打開定製的壓測頁面，新增數據，腳本中帳戶密碼參數化500個帳號。實際包含一次百萬級數據查詢和一次刪除、兩次插入的數據庫操做。 
  壓測場景：沒有集合點和思考時間，模擬緩存壓測，500併發

2.2.二、計算資源標準化

  本次測試環境爲內網環境，千兆帶寬 
  軟硬件配置： 
    4臺web服務器：Linux系統，4核8G，web應用基於Ecloud容器部署 
    Nginx服務器：Linux系統，4核8G，nginx基於Ecloud容器部署 
    Redis服務器：Linux系統，4核8G，redis基於Ecloud容器部署 
    Mysql服務器：Linux系統，8核32G，磁盤IOPS限制在5000

2.2.三、測試工具標準化

  性能測試工具：Loadrunner11.0

2.三、測試結果

2.3.一、讀數據場景測試結果

  讀數據場景，在單機web服務器cpu達到瓶頸時採集壓測數據，後在集羣模式下，經過水平擴展web服務器，直到擴展到4臺web服務器，全部場景下都爲web服務器CPU先到瓶頸。 
  測試結果數據： 

測試條件	測試結果		服務器CPU
系統架構	事務響應時間	QPS（HPS）	Web1	Web2	Web3	Web4	Redis	Nginx	數據庫
單機部署	0.51s	973.982			87.7%				14.1%
兩臺集羣	0.228s	2092.321	88.6%		84.3%		11.9%	13.1%	32.8%
三臺集羣	0.154s	3107.397	93.2%		89.2%	88.6%	18.5%	20.1%	40.3%
四臺集羣	0.125s	3992.368	90.4%	85.3%	84.8%	87.4%	20.3%	18.6%	52.1%

2.3.二、寫數據場景測試結果

  寫數據場景，在單機web服務器cpu達到瓶頸時QPS爲671，後在集羣模式下，經過水平擴展web服務器，直到擴展到4臺web服務器，全部場景下都爲web服務器CPU先到瓶頸。 
  測試結果數據：

測試條件	測試結果		服務器CPU							IOPS
系統架構	事務響應時間	QPS（HPS）	Web1	Web2	Web3	Web4	Redis	Nginx	數據庫	數據庫
單機部署	0.744s	671.699			91.5%				21.8%	2221
兩臺集羣	0.406s	1228.961	93.8%		84.6%		41.2%	14%	40.7%	2687.5
三臺集羣	0.259s	1933.576	94.6%		92.8%	94.1%	51.7%	17.8%	52%	3314
四臺集羣	0.19s	2627.384	95.2%	89.6%	87.9%	88.7%	58.5%	23.9%	59.8%	3344

3、發現與結論

3.一、基礎結論

  就目前壓測的兩個場景：讀數據、寫數據，在web服務器cpu達到瓶頸的狀況下，其餘性能指標均未達到瓶頸的狀況下，集羣模式經過水平擴展web服務器，可實現處理性能（以QPS爲衡量指標）線性增加； 
  單純的讀數據場景下，每增長一臺4核8G服務器，系統QPS值提高1000左右； 
  單純的寫數據場景下，每增長一臺4核8G服務器，系統QPS值提高650左右。

3.二、推論

  基於上述數據，可得出基線指標的結論爲：爲F9框架系統部署提供硬件資源，每個CPU核，可支撐系統性能表現QPS值在160~250之間，若是實際壓測時，依照投入的資源狀況，評測出系統性能表現低於此區間的，則認爲性能達不到基線標準，須要進行系統調優。

4、補充說明

4.一、數據庫磁盤IOPS爲什麼限制在5000？

  在本次性能基線測試中，預先對數據庫服務器的磁盤進行了IOPS值的限制，限制值爲5000。 
  1、爲何要限制IOPS？ 
  由於根據實際項目經驗，不少項目的沒有特別強悍的數據庫服務器，特別是磁盤IOPS，每每會成爲系統瓶頸所在，本次測試經過限制IOPS值，也同步驗證下F9框架在特定IOPS極限值下是否能夠知足性能需求。 
  2、爲何限制在5000？ 
  5000這個數值，也是根據性能調優人員經驗肯定。可認爲，數據庫服務器磁盤IOPS 5000是基本的硬件指標要求，若是低於此值，能夠認爲硬件條件不達標，難以知足大型項目高併發要求，須要調整數據庫服務器資源投入。 
  另外，許多項目使用虛擬機做爲數據庫服務器，且使用共享磁盤，IOPS能力也被分佔，每每達不到5000 IOPS的要求，因此在大型項目或對系統性能有必定要求的項目中，不推薦使用虛擬機做爲數據庫服務器。

4.二、通俗化的性能基線指標

  因爲目前的性能需求每每都是併發+響應時間這樣的描述，並不能對應的了QPS值，沒法指導計算資源評估，爲了將性能基線通俗化，須要進行一下換算。考慮到事務複雜度不一，爲了便於換算，統一預估單事務平均包含10個請求，單事務響應時間爲3秒。基於單機器4核8G，QPS值爲650~1000之間，依照換算公式「併發=QPS/單事務請求數*事務響應時間」，支撐併發量爲195~300之間。故通俗化的基線指標爲，單臺4核8Gweb服務器，支持用戶併發195~300間。按此，一個須要知足1000併發量要求的系統，大體須要4臺4核8Gweb服務器。