衡量軟件性能三大常用指標：並發用戶數、響應時間、系統吞吐量
並發用戶數，是性能需求與測試最常用，也是最重要的指標之一。它包含了業務層面和后端服務器層面 的兩層含義。
- 業務層面的並發用戶數，指的是實際使用系統的用戶總數。但是，單靠這個指標並不能反映系統實 際承載的壓力，我們還要結合用戶行為模型才能得到系統實際承載的壓力。
- 后端服務器層面的並發用戶數，指的是“同時向服務器發送請求的數量”，直接反映了系統實際承載的壓力。
響應時間
通俗來講，響應時間反映了完成某個操作所需要的時間，其標准定義是“應用系統從請求發出開始，到 客戶端接收到最后一個字節數據所消耗的時間”，是用戶視角軟件性能的主要體現。
響應時間，分為前端展現時間和系統響應時間兩部分。其中，前端時間，又稱呈現時間，取決於客戶端 收到服務器返回的數據后渲染頁面所消耗的時間；而系統響應時間，又可以進一步划分為Web服務器時 間、應用服務器時間、數據庫時間，以及各服務器間通信的網絡時間。
嚴格來講，響應時間應該包含兩層含義：技術層面的標准定義和基於用戶主觀感受時間的定義。 而在性能測試過程中，我們應該使用哪個層面的含義將取決於性能測試的類型。顯然，對於軟件服務器端的性能測試肯定要采用標准定義，而對於前端性能評估，則應該采用用戶主觀感受時間的定義。
系統吞吐量
系統吞吐量，是最能直接體現軟件系統負載承受能力的指標。
這里需要注意的是，所有對吞吐量的討論都必須以“單位時間”作為基本前提。其實，我認為 把“Throughput”翻譯成吞吐率更貼切，因為我們可以這樣理解：吞吐率=吞吐量/單位時間。但既然國內很多資料已經翻譯為了“吞吐量”，所以通常情況下我們不會刻意去區分吞吐量和吞吐率，統稱為吞吐 量。
對性能測試而言，通常用“Requests/Second”“Pages/Second”“Bytes/Second”來衡量吞吐量。當然，從 業務的角度來講，吞吐量也可以用單位時間的業務處理數量來衡量。
以不同方式表達的吞吐量可以說明不同層次的問題。比如：
“Bytes/Second”和“Pages/Second”表示的吞吐量，主要受網絡設置、服務器架構、應用服務器制 約； “Requests/Second”表示的吞吐量，主要受應用服務器和應用本身實現的制約。
這里需要特別注意的是：雖說吞吐量可以反映服務器承受負載的情況，但在不同並發用戶數的場景下， 即使系統具有相近的吞吐量，但是得到的系統性能瓶頸也會相差甚遠。
並發用戶數、響應時間、系統吞吐量之間關系
- 當系統並發用戶數較少時，系統的吞吐量也低，系統處於空閑狀態，我們往往把這個階段 稱為 “空閑區間”。
-
當系統整體負載並不是很大時，隨着系統並發用戶數的增長，系統的吞吐量也會隨之呈線 性增長，我們往往把這個階段稱為 “線性增長區間”。
- 隨着系統並發用戶數的進一步增長，系統的處理能力逐漸趨於飽和，因此每個用戶的響應 時間會逐漸變長。相應地，系統的整體吞吐量並不會隨着並發用戶數的增長而繼續呈線性 增長。我們往往把這個階段稱為系統的“拐點”。
- 隨着系統並發用戶數的增長，系統處理能力達到過飽和狀態。此時，如果繼續增加並發用 戶數，最終所有用戶的響應時間會變得無限長。相應地，系統的整體吞吐量會降為零，系 統處於被壓垮的狀態。我們往往把這個階段稱為“過飽和區間”。