筆記（茹炳晟老師 第28課 帶你一起解讀不同視角的軟件性能與性能指標 ）
衡量軟件性能三個最常用的指標：併發用戶數、響應時間、系統吞吐量
併發用戶數
包含業務層面和後端服務器層面的兩層含義
業務層面的併發用戶數：指實際使用系統的用戶總數。要結合用戶行爲模型，才能得到系統實際承載的壓力。
後端服務器層面的併發用戶數：同時向服務器發送請求的數量--直接反映了系統實際承載壓力。
系統潛在用戶數、業務併發用戶、實際併發用戶數（服務器併發請求數）--取決於業務併發用戶數和用戶行爲模式，用戶行爲模式比重較大
性能測試中關鍵一環：分析得到準確的用戶行爲模式（除了獲取性能需求外，最困難的工作）
獲取用戶行爲模式方法：
1）以上線系統：系統日誌分析法-->獲取用戶行爲統計和峯值併發量等重要信息
2）未上線系統：參考行業中類似系統的統計信息建模、分析（通常做法）
響應時間
通俗定義：反映了完成某個操作所需要的的時間
標準定義：應用系統從請求發出開始，到客戶端接收到最後一個字節數據所消耗的時間
- 服務器端響應時間：採用標準定義評估
- 前端響應時間：採用用戶主觀感受時間的定義
系統吞吐量
最直接體現軟件系統負載承受能力的指標
注意：所有對吞吐量的討論都必須以“單位時間”作爲基本前提
衡量吞吐量
- Requests/Second 受應用服務器和應用本身實現制約
- Pages/Second 受網絡設置、服務器架構、應用服務器制約
- Bytes/Second 受網絡設置、服務器架構、應用服務器制約
從業務角度，也可以用 “單位時間的業務處理數量” 衡量
【注意】 不同併發用戶數場景下，即使系統具有相近的吞吐量，但是得到的系統性能瓶頸也會相差甚遠
【要求】性能測試場景指標，需要根據實際情況組合併發用戶數、響應時間這兩個指標
考察HTTP或業務層面：Requests/Second、Pages/Second
考察系統層面或網絡層面：Bytes/Second
併發用戶數、系統吞吐量、響應時間三者關係
當系統併發用戶數較少時，系統的吞吐量也低，系統處於空閒狀態--稱爲“空閒區間”
當系統整體負載並不是很大時，隨着系統併發用戶數的增長，系統的吞吐量也會隨之線性增長--稱爲“線性增長區間”
隨着系統併發用戶數的進一步增長，系統的處理能力逐漸趨於飽和，因爲每個用戶的響應時間會逐漸變長。相應的，系統的整體吞吐量並不會隨着併發用戶的增長而繼續呈線性增長--稱爲“拐點”
隨着系統併發用戶數的增長，系統處理能力達到過飽和狀態。此時，如果繼續增加併發用戶數，最終所有用戶的響應時間會變得無限長。相應地，系統的整體吞吐量會降爲零，系統處於被壓垮的狀態。--稱爲“過飽和區間”