文章中介紹乙個理髮店理論，然後引出最佳併發使用者數和最大併發使用者數的概念
背景：理髮店共有3名理髮師，每名理髮師完成一次理髮都耗時1小時，店裡有還有一些位子供客人等位，每個客人在理髮店呆的時間超過3小時就會無法忍受離開。
我理解的幾個概念
3名理髮師，好比應用同時能處理幾個事務
理髮耗時1小時，好比完成一次事務需要的時間
（等待位子，加上能剪髮的位子，好比最大請求佇列數）
3小時，好比響應時間，超過3小時，則放棄這個請求
結合場景，從上圖可以看出，隨著理髮店客人的數量增加時，響應時間一開始並沒有明顯變化，因為有3個理髮師，足矣消化掉3個客人，當超過3個客人時，勢必有客人是需要等待的。
在客人數量正好為3人時，理髮師的工作效率最高，客人也不需要等待，這個數我就理解為 最佳併發使用者數
而當客人數為9人時，在這個場景中，勢必有客人完成理髮的時間要達到2-3小時了（來的時候，其他客人已經剪到一半了，需要等正在剪的客人0-1小時，前面排在前面的人理髮1小時，自己理髮1小時），而再來客人的話，必定完成理髮的時間超過3小時，也就是所謂的超時放棄走人了。
這個9，我就理解為 最大併發使用者數
所謂的效能，是負載、吞吐量、可接受的響應時間和資源利用率之間的一種平衡。
下面的文字摘錄的，很受用：
對於乙個確定的被測系統來說，在某個具體的軟硬體環境下，它的「最佳併發使用者數」和「最大併發使用者數」都是客觀存在。以「最佳併發使用者數」為例，假如乙個系統的最佳併發使用者數是50，那麼一旦併發量超過這個值，系統的吞吐量和響應時間必然會 「此消彼長」；如果系統負載長期大於這個數，必然會導致使用者的滿意度降低並最終達到一種無法忍受的地步。所以我們應該 保證最佳併發使用者數要大於系統的平均負載。要補充的一點是，當我們需要對乙個系統長時間施加壓力——例如連續加壓3-5天，來驗證系統的可靠性或者說穩定性時，我們所使用的併發使用者數應該等於或小於「最佳併發使用者數」——大家也可以結合上面的討論想想這是為什麼 ^_^而對於最大併發使用者數的識別，需要考慮和鑑別一下以下兩種情況：
1. 當系統的負載達到最大併發使用者數後，響應時間超過了使用者可以忍受的最大限度——這個限度應該**於效能需求，例如：在某個級別的負載下，系統的響應時間應該小於5秒。這裡容易疏忽的一點是，不要把顧客因為無法忍受而離開時店內的顧客數量作為理髮店的「最大併發使用者數」，因為這位顧客是在3小時前到達的，也就是說3小時前理髮店內的顧客數量才是我們要找的「最大併發使用者數」。而且，這位顧客的離開只是乙個開始，可能有會更多的顧客隨後也因為無法忍受超長的等待時間而離開；
2. 在響應時間還沒有到達使用者可忍受的最大限度前，有可能已經出現了使用者請求的失敗。以理髮店模型為例，如果理髮店只能容納6位顧客，那麼當7位顧客同時來到理髮店時，雖然我們可以知道所有顧客都能在可容忍的時間內剪完頭髮，但是因為理髮店容量有限，最終只好有一位顧客打道回府，改天再來。
對於乙個系統來說，我們應該 確保系統的最大併發使用者數要大於系統需要承受的峰值負載。
併發使用者數和QPS
關於併發使用者數和qps，自己一直被這兩個概念糾結，閱讀了一下相關資料，總結如下 併發 使用者數和qps兩個概念沒有直接關係，但是如果要說qps時，一定需要指明是多少併發使用者數下的qps，否則豪無意義，因為單使用者數的40qps和20並 發使用者數下的40qps是兩個不同的概念。前者說明該應用可以...
LoadRunner 虛擬使用者數和併發使用者數的聯絡
oa系統使用使用者是100個，這個就是系統使用者數。承受的壓力。因為伺服器 併發使用者 是同時執行乙個操作的使用者，或者是同時執行指令碼的使用者，這個併發在設定不同場景的時候併發的情況是不一樣的，在實際的測試 估算併發數的公示 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c ...
併發使用者數的理解
什麼是併發使用者數，很多人都會拿這個指標來衡量乙個網路系統的好與壞，剛開始接觸loadrunner的時候，曾認為虛擬使用者就是所謂的併發使用者數，不過經過一系列的測試後，發現這種看法並不怎麼全是正確。首先，要分兩種測試情況，第一種是通過跑網頁實際業務測試，如教務系統，觀察其登陸事務，查詢事務等，第二...