我們在性能測試的過程中，有產品經理或技術總監 經常會問：我們的系統 支持多少並發用戶數？
為什么我們要關注 並發用戶數這個指標呢？
首先來談談 為啥 要關注 用戶數 這個指標： 在性能測試的基准性測試過程中，一個線程代表一個 VU（虛擬用戶），
隨着 並發用戶數的增加 理論上被測系統接收到的並發請求數越多，但當並發用戶數 並發的請求達到一定的量之后，系統無法繼續處理更多的請求；這時會導致系統出現瓶頸甚至可能出現系統崩潰。
我們可能會出現的瓶頸是 系統資源利用率超過警戒值、事務的平均響應時間 延長 甚至有部分的請求超時、系統的處理能力開始下降等。
我們通過利用不用的並發用戶數對系統 加壓的過程，找出系統的拐點，同時也可以知道 多少個用戶同時在線操作 我們的系統是正常的，最大多少用戶數操作時 系統會出現性能下降；
這樣我們通過這個並發用戶數的加壓測試過程的得出的 性能指標結果分析，優化我們的 業務性能、架構節點、硬件資源容量、應用程序算法 等等。
因此 尋找系統支撐多少並發用戶數 是 尋找系統瓶頸的 一個手段之一。
那我們如何來測試 系統支撐多少並發用戶數呢？
我們來設定一個業務場景：
如果 一家醫院有20個科室， 每個科室有5個醫生 ，每天每個醫生看病100個病人 ，單個科室看病5個醫生×100個病人= 500人 1天需掛號500病人×20個科室=1萬人，看病的周期為5天，則為1萬人×5天=5萬人。
現在假設有50家醫院 則一個禮拜需要處理 5萬人×50家醫院=250萬 個預約掛號操作
假設（這里的數據都是假設） 掛號是每周5晚上22點 開始開放，通過埋點 數據得知： 80%的人會在22點-24點之間 提前預約掛好號。則為2個小時 需要處理 250萬*80%=200萬筆預約掛號業務。
則2個小時的 處理數據為200萬，我們得出TPS=200萬/3600/2=277 TPS
設定 1個TPS包含了 5個接口 則qps（預估）=277*5=1385個請求/秒 （這里得到的只是計算出來的預估請求數）
假定 在做單業務基准測試時，拿 這個 預約掛號的 5個接口 單線程 循環迭代1000次，延遲時間為0，運行時間不限制， 跑完 算出 實際的qps = 總的請求數/ 實際運行時間
如果 實際測試的 qps= 50 個請求/秒 ，這里是指1個線程 處理 預約掛號 每秒鍾需要處理的 請求。（這里基准得qps 以服務器端監控為准）
（疑惑點：估計有人會疑惑 為啥 單個線程去跑這個基准得qps呢？
解答：比如 你一個人過獨木橋，與2個人並行或串行過獨木橋，誰得速度快呢？當然是一個人過獨木橋是最快得，所以單個線程得出得結果是最大得， 被除數不變，除數變大，商是不是最小呢？）
我們壓測過程中就以得出得並發用戶數開始壓測，可以縮短探索並發用戶數的時間，在沒有埋點數據得情況下我們就可以通過計算獲得預估得初始起點 最小並發用戶數。
假定我們每個線程的處理能力都是一樣的（實際不一樣），這樣我們就算出一個 最小的並發用戶數（預估）=qps（預估）1385個請求/秒 ÷ 實際測試的qps 50 個請求/秒 =27.7 ≈28
為啥 最小並發用戶數 = 預估的qps ÷ 實際測試的qps， 表示的是1個人（1個線程）能夠完成的工作量，在相同時間內 要完成 總的工作量，相除就得出 多個人在同一時間完成的工作量。
比如 一個人在1秒鍾能夠吃1個月餅（實際能力），我現在有10個月餅（預估要達成的目標） 需要在一秒鍾吃完，則需要 10個月餅/秒 ÷ 1個月餅/秒 =10個人 同時並發吃月餅。
至於 要吃完 100個月餅，1個人並發的TPS 與 5個人並發的TPS 10個人的TPS 會呈現 先線性增長隨后變成 平穩 再到 降低的 一個曲線
這樣，我們就可以通過 預估的最小並發用戶數 作為測試的 起點 來 進行負載壓力測試時，找出系統瓶頸的拐點。得出一個最佳並發用戶數、最大並發用戶數。
TPS是衡量業務處理能力是否滿足系統處理能力的指標。
qps是TPS的另外一種接口請求的技術型表達方式。
吞吐率是通過數據字節的方式 對網絡 與 內存等容量單位的 一種評估手段。
資源利用率是評估服務器的軟硬件能力瓶頸的表達方式。
中間件的性能指標是 建立在不同的硬件資源服務器和 配置文件配置 以及 節點的基礎上的 一個能力，這個中間件的基礎能力可以通過中間件自帶的 基准性測試工具來測試評估得出，做全鏈路壓測時也可以測試出當前得測試數據 是否超過 基准性測試得參數配置性能，超過則出現了中間件瓶頸。
數據庫的性能指標 可以通過2種方式來評估：1是通過基准性測試工具來評估本身的 最佳性能 2是在現有配置情況下業務數據來測試 數據庫的 explain、緩存命中率、行數正確性、覆蓋索引不能回表、聯合索引不能無限建、給字符串加索引、索引排序問題、數據庫內存讀寫能力、磁盤讀寫能力、數據庫連接池問題等。