一、背景與說明
1.1、性能基線的背景與意義
當系統的操作響應時間超出了用戶可接受的程度，說明系統出現了性能問題，需要技術人員對系統進行優化，但是 “用戶是否可接受”是一個主觀的無法直接測量的標准，具體在何種程度下需要開啟對系統性能的優化工作，又優化到何種程度后可以終止工作，沒有統一的度量標准。
另外，真正引起性能問題的原因不僅僅是程序代碼，也可能是承載系統運行的計算資源不充足，那么如何讓性能優化人員明確目前到底是應該擴充計算資源還是修改程序代碼，也需要有統一的指導標准和原則。
在這些問題背景下，性能基線就顯得十分必要。性能基線的含義就是在可控的標准化的環境下，通過測試工具采集和人工分析后得出的有參考價值的指標數據。概括的來說，這些指標數據的主要作用如下：
1.為容量規划確定系統和應用程序的極限；
2.為配置測試的參數和配置選項提供參考依據；
3.為驗收測試確定系統是否具備自己所宣稱的能力；
4.為性能基線的建立提供長期的數據統計來源以及比較基准。
1.2、預期讀者與目標
系統架構師或技術負責人：依照系統性能需求，參照性能基線測算計算資源需求；
性能測試人員：了解性能基線指標值，能夠在測試環境中計算資源不充足的情況下，也對系統的性能表現進行測試並把關，明確系統性能是否達到基線要求，性能測試是否可以通過；
性能調優人員：為性能調優建立目標，只有系統性能表現滿足基線指標值，方可完成性能調優工作。
1.3、性能基線指標選擇
1.3.1、性能指標相關名詞解釋
QPS：每秒請求處理量(Query Per Second)，是對一個特定的應用系統在規定時間內所處理流量多少的衡量標准。通俗講即，每秒鍾處理完請求的次數，注意這里是處理完，具體是指發出請求到服務器處理完成功返回結果；
事務（Transaction）：一組請求，事務的開始和事務的結束在錄制壓測腳本時定義，事務中包含的請求視具體業務場景而定，故事務中請求的數量無法固定有多有少。例如：用戶登錄作為一個事務，里面包含了登錄頁面加載、登錄驗證請求、首頁面菜單數據請求、消息提醒請求、元件頁面加載請求等多個服務器請求；
並發：系統能同時處理的事務數，在loadrunner壓測工具里，並發一般指設置的並發用戶數Vuser的數量；
TPS：Transaction Per Second，每秒鍾系統可執行完成的事務的數量。
並發、QPS、TPS間的關系：
QPS = TPS*事務包含請求數量
並發數 = (QPS/事務包含請求數量)*事務平均響應時間
並發數 = TPS*事務平均響應時間
1.3.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也不能用來作為性能極限指標。
三、為什么要使用QPS作為性能基線指標？
請求作為構成服務器壓力的原子單位，單位時間內處理請求數（QPS）相較上述指標來說，更易作為跨系統、不同硬件環境下性能對比的統一標准。
還是上述A、B系統為例，A系統場景10個請求，150TPS，換算為QPS為1500，B系統場景15個請求，100TPS，換算為QPS也是1500，雖然到請求級別，也會存在復雜度偏差，但基於統計與比較基准需要，可以認為A、B兩套系統的性能表現持平或者是接近，並非A系統表現比B好很多。
四、還需要加入硬件資源的考量因素
上述A、B系統，假設前提是使用了相同的硬件資源條件，但是在實際情況下，不同系統部署使用的硬件資源是不一樣的，如果A系統使用了更好的資源，性能表現優於B系統，也無法說明A系統的程序性能優於B系統。
故性能基線除了QPS值以外，還需要加入硬件資源的考量因素，最終性能基線的指標為：單位硬件資源（如單台應用服務器4核8G內存）下，系統壓測的QPS極值。
二、性能基線測試
2.1、測試目的與策略
基線測試的目的是得到壓測基礎數據，便於后續推導出性能基線指標。
主要的測試策略：
1.構建可控環境，提供標准化的測試場景、測試工具和測試環境資源；
2.使用壓測工具，測試同一場景，通過不斷改變硬件資源投入，分別獲得系統QPS極值。
2.2、測試准備
2.2.1、測試場景標准化
場景一、讀數據場景
腳本概述：訪問用戶登錄頁，輸入賬戶密碼后，等待加載首頁完，在個人消息中心里進行搜索(搜索條件為空) ，腳本中賬戶密碼參數化500個賬號。實際包含對一張數據量100萬級別的數據表進行2次數據庫查詢操作。
壓測場景：沒有集合點和思考時間，模擬緩存壓測，500並發
場景二、寫數據場景
腳本概述：訪問用戶登錄頁，輸入賬戶密碼后，等待加載首頁完，打開定制的壓測頁面，新增數據，腳本中賬戶密碼參數化500個賬號。實際包含一次百萬級數據查詢和一次刪除、兩次插入的數據庫操作。
壓測場景：沒有集合點和思考時間，模擬緩存壓測，500並發
2.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.3、測試工具標准化
性能測試工具：Loadrunner11.0
2.3、測試結果
2.3.1、讀數據場景測試結果
讀數據場景，在單機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.2、寫數據場景測試結果
寫數據場景，在單機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.1、基礎結論
就目前壓測的兩個場景：讀數據、寫數據，在web服務器cpu達到瓶頸的情況下，其他性能指標均未達到瓶頸的情況下，集群模式通過水平擴展web服務器，可實現處理性能（以QPS為衡量指標）線性增長；
單純的讀數據場景下，每增加一台4核8G服務器，系統QPS值提升1000左右；
單純的寫數據場景下，每增加一台4核8G服務器，系統QPS值提升650左右。
3.2、推論
基於上述數據，可得出基線指標的結論為：為F9框架系統部署提供硬件資源，每一個CPU核，可支撐系統性能表現QPS值在160~250之間，如果實際壓測時，依照投入的資源情況，評測出系統性能表現低於此區間的，則認為性能達不到基線標准，需要進行系統調優。
四、補充說明
4.1、數據庫磁盤IOPS為何限制在5000？
在本次性能基線測試中，預先對數據庫服務器的磁盤進行了IOPS值的限制，限制值為5000。
一、為什么要限制IOPS？
因為根據實際項目經驗，很多項目的沒有特別強悍的數據庫服務器，特別是磁盤IOPS，往往會成為系統瓶頸所在，本次測試通過限制IOPS值，也同步驗證下F9框架在特定IOPS極限值下是否可以滿足性能需求。
二、為什么限制在5000？
5000這個數值，也是根據性能調優人員經驗確定。可認為，數據庫服務器磁盤IOPS 5000是基本的硬件指標要求，如果低於此值，可以認為硬件條件不達標，難以滿足大型項目高並發要求，需要調整數據庫服務器資源投入。
另外，許多項目使用虛擬機作為數據庫服務器，且使用共享磁盤，IOPS能力也被分占，往往達不到5000 IOPS的要求，所以在大型項目或對系統性能有一定要求的項目中，不推薦使用虛擬機作為數據庫服務器。
4.2、通俗化的性能基線指標
由於目前的性能需求往往都是並發+響應時間這樣的描述，並不能對應的了QPS值，無法指導計算資源評估，為了將性能基線通俗化，需要進行一下換算。考慮到事務復雜度不一，為了便於換算，統一預估單事務平均包含10個請求，單事務響應時間為3秒。基於單機器4核8G，QPS值為650~1000之間，依照換算公式“並發=QPS/單事務請求數*事務響應時間”，支撐並發量為195~300之間。故通俗化的基線指標為，單台4核8Gweb服務器，支持用戶並發195~300間。按此，一個需要滿足1000並發量要求的系統，大致需要4台4核8Gweb服務器。