在做效能測試的時候，我們常常聽到併發使用者、響應時間、吞吐量專業術語，也許大家都理解，這裡有一個理解的層次與深度概念。最近有看斷念《軟體效能詳解與案例分析》一書，看了他的講解，原來我對這些術語的理解還是比較膚淺，其實，這裡也主要受制於自己的知識面。所以，再拿出來與大家重溫一下。
併發使用者數
大家都知道我們的效能測試就通過工具模擬多使用者對系統進行操作，對系統造成壓力，來驗證系統的效能（不太標準的解釋）。好多人也簡單的把效能測試當成併發測試。那麼這個“多使用者”和“同時”兩個因素缺一不可。只多使用者不同時，很難對系統構成壓力；沒有多個使用者，同時的概念也就自然不存在了
併發的兩種情況
一種是嚴格意義上的併發，即所有的使用者在同一時刻做同一件事或操作，這種操作一般指做同一型別的業務。比如，所有使用者同一時刻做併發登陸，同一時刻做表單提交。
另外一種併發是廣義範圍的併發，這種併發與前一種併發的區別是，儘管多個使用者對系統發出了請求或者進行了操作，但是這些請求或都操作可以是相同的，也可以是不同的。比如，在同一時刻有使用者在登入，有使用者在提交表單。
從伺服器的角度來看併發
前面的兩種解釋都是從使用者業務的角度來解釋併發的，因為我們平時所做的效能測試也是從使用者端對業務層的操作來進行併發測試的。
如果考慮整個系統執行過程中伺服器所承受的壓力是這樣的：在該系統的執行過程中，把整個執行過程劃分為離散的時間點，在每個點上，都有一個“同時向服務端傳送請求的客戶數”，這個就是所謂的伺服器所承受的最大併發訪問數。
真正意義上的併發不存在
上面試談了這麼多併發，現在又說真正意義上的併發不存在。何解？學作業系統原理的同學都知道，CPU在一個時間點上只能幹一件事兒。為什麼我們可以邊看電影，邊打字，邊語音。因為CPU很快很快，他可以處理一下電影，再處理一下打字，再處理一下語音。因為它很快，所以，它可以在多個程式之間快速瞬間的切換，給你造成的假象就是它在同時做這些事情。（現在的雙核、四核的CPU另說）
那麼我們的系統在接到使用者的請求後也要呼叫CPU來完成某些處理，然後返回給使用者。那麼我們對系統有做併發測試是測什麼呢？舉個簡單的例子。假如有一位神醫，他的看病速度非常快，假設他的看病速度是不變的；然後有一群接待人員來接待看病的客人，有成千上萬的病人來看病，接待人員要想各種辦法來做好接待工作，使病人更快的看到病。比如，可以事先諮詢病人得的什麼病，然後將病人進行分類，比如可以擴大接待室，讓更多的病人可以進到醫院來看病等。
神醫就是我們的CPU，接待人員就是我們的系統，病人就使用者，我們做效能測試的目的就是了解接待人員哪個地方給醫院看病造成了瓶頸。只來一個病人，醫院的看病速度與服務很好。一下子來十萬個病人各種問題就出來了。接待人員的服務態度下降，多餘的人員跟本進不到醫院去，醫院的洗手間不夠用，造成病人無法上則所而離開，這些都屬於系統問題。所以，我們一般測試的目的是看醫院的接待能力。
系統使用者數與同時線上人數
在實際的效能測試中，經常接觸到與併發使用者相關的概念還有“系統使用者數”與“同時線上人數”下面通過一個例項來描述他們之間的差別。
假設有一個網站，註冊使用者才能登入使用各種功能，如上傳頭像，閱讀專家文章等。該系統有20萬註冊使用者，這就是說有20萬用戶可以使用這個網站的所有功能，20萬就是這個網站的“系統使用者數”，網站有一個線上統計功能，從統計資料中可以看到，同時登入網站的人數的最高記錄是2萬，就是有2萬人同時用瀏覽器開啟著這個網站。2萬就是“同時線上人數”
那麼系統的併發使用者數是多少呢?2萬麼？NO!這2萬隻表示在系統最高峰時有這麼多使用者登入了網站，並不表示實際伺服器的承受壓力。因為伺服器承受壓力還與具體的使用者訪問模式相關，在這2萬用戶中考察某一個時間點對使用者發出請求數，可以會大大縮水。那麼，該系統的服務端承受的最大併發訪問數是多少呢？這個取決於業務併發使用者數和業務場景，一般可以通過伺服器日誌的分析得到。
求併發使用者數公式
在實際的效能測試工作中，測試人員一般比較關心的是業務併發使用者數，也就是從業務的角度關注應該設定多少個併發數比較合理。
下面找一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鐘的時間裡使用者會登入簽到系統進行簽到。公司員工為1000人，平均每個員上登入簽到系統的時長為5分鐘。可以用下面的方法計算。
C=1000*5/30=166.7
C表示平均併發使用者數，那麼對這個簽到系統每秒的平均併發使用者數為166
當然，在效能測試上，任何公式都不是嚴謹的，最重要的是對系統做出有效正確的分析。