併發：
一種是所有使用者在同一時刻做同乙個操作；
一種是多個使用者對系統進行了操作（此操作可相同可不同）。
求併發使用者數公式：
在實際的效能測試工作中，測試人員一般比較關心的是業務併發使用者數，也就是從業務的角度關注應該設定多少個併發數比較合理。
下面找乙個典型的上班簽到系統，早上8點上班，7點半到8點的30分鐘的時間裡使用者會登入簽到系統進行簽到。公司員工為1000人，平均每個員上登入簽到系統的時長為5分鐘。可以用下面的方法計算。
c=1000/30*5=166.7
當然，在效能測試上，任何公式都不是嚴謹的，最重要的是對系統做出有效正確的分析。
吞吐量：
一次效能測試過程中網路上傳輸的資料量的總和。可以說明系統的負載能力。
吞吐率：單位時間內網路上傳輸的資料量，也可是單位時間內處理客戶請求數量。通常情況下用「位元組數/秒」「請求數/秒」「頁面數/秒」來衡量。
從業務角度也可以用「業務數/小時或天」「訪問人數/小時或天」「頁面訪問量/小時或天」來衡量。
吞吐量的意義：通過設計效能測試場景。檢驗結果是否達到預期設計目標；用於協助分析效能瓶頸。
rbi（rapid bottleneck identify）：
是empirix公司提出的快速識別系統效能瓶頸的方法。該方法基於以下事實。
1. 發現的80%系統的效能瓶頸都由吞吐量制約；
2. 併發使用者數和吞吐量瓶頸之間存在一定的關聯；
3. 採用吞吐量測試可以更快速定位問題。
通過不斷增加併發使用者數和吞吐量觀察系統的效能瓶頸。然後，從網路、資料庫、應用伺服器和**本身4個環節確定系統的的效能瓶頸。
事務：使用者某一步或幾步的操作集合。
tps（每秒事務數）：衡量伺服器對事務的處理能力。每秒系統能處理事務或交易的數量。
點選率：可看作是tps的一種特定情況。點選率更能體現使用者端對伺服器的壓力，即每秒鐘使用者向web伺服器提交的http請求數；當每次點選定義為乙個交易時，點選率=tps；點選率越大，對伺服器的壓力也越大。
響應時間=呈現時間+資料傳輸時間+系統處理時間；即客戶從發起乙個請求開始到收到最後乙個位元組的響應所耗費的時間。對此，有2/5/10的通用原則作為一般依據。
【內容摘自蟲師博文---效能測試知多少系列】
效能測試需要關注的效能點
我們站在管理員的角度考慮需要關注的效能點 1 相應時間 2 伺服器資源使用情況是否合理 3 應用伺服器和資料庫資源使用是否合理 4 系統能否實現擴充套件 5 系統最多支援多少使用者訪問 系統最大業務處理量是多少 6 系統效能可能存在的瓶頸在 7 更換那些裝置可以提高效能 8 系統能否支援7 24小時...
效能測試關注的指標
效能測試關注的點 1 客戶端響應時間 2 throughput 吞吐量 系統吞吐量幾個重要引數 qps tps 併發數 響應時間 qps tps 每秒鐘request 事務 數量 併發數 系統同時處理的request 事務數 理解了上面三個要素的意義之後，就能推算出它們之間的關係 qps tps 併...
效能測試關注的幾個指標以及檢視命令
參考檔案 5種協議 http https websocket socket mqtt 加密 aes des rsa md5 sha1，自有加密演算法包呼叫 效能指標 併發使用者數 錯誤率 吞吐量 每秒點選數 每秒響應數 事務平均響應時間 每秒事務數 每秒事務總數等 基礎硬體指標 cpu 記憶體 磁碟...