當我們在談論“並發”時

動輒要求系統支持成百上千並發的性能需求太多了，也許系統在實際中確實存在這樣的需求，但能夠較全面理解此需求的情況並不多。

對於並發，我過去接觸了幾種理解，在接觸的第一種理解中，“並發”是由loadrunner中獲取，即腳本中所有或部分vuser執行至集合點函數時進行停留，等待觸發條件發生以後，同時執行集合點函數後的請求操作的這一個過程，為“並發”（這一個請求操作一般存在多個http請求），可惜這種“並發”是無法直接用於衡量系統性能的。而在接觸的第二種理解中，“並發”的理解是相對於服務器某一個時間區間內接收的請求數，也就是每秒的點擊率（loadrunner考慮到這點，也就是analysis裏面的hits/s），為“並發”，這種“並發”是可以用於對系統性能狀況進行量化的，但是這種測試思想只是比較片面的從性能指標的角度去衡量系統性能，不能體現出系統性能帶給用戶何種性能體驗（這也是不少開源性能測試工具的問題）。

前一種“並發”的理解普遍獲得了loadrunner初級用戶的認可，後一種“並發”的理解普遍獲得系統運維、開發人員的認可，在溝通中為了方便區別開來，在兩種角色裏面，當大家意識到並發的理解存在差異時，大家把前一種被稱為“狹義上的並發”，而後一種被稱為“廣義上的並發”。後來，又從淘寶團隊裏面了解了一種定義，貌似淘寶QA把“並發”定義為一個完整的事務請求數量過程（loadrunner也考慮到這點，也就是analysis裏面的Transactions per Second）。一直以來，還有一種技術範圍以外對“並發”的粗略的理解被第三方測試拿來用了，那就是用戶在線數中的某個百分比即並發數。

如果一個團隊裏面對“並發”的理解有這麽多種，那麽當我們在討論性能需求的“支持並發數”時，我們究竟在討論什麽呢？

個人認為，有一部分的原因是由於loadrunner是惠普saas（軟件即服務的解決方案）的一部分，所以並不是一個純粹技術人員使用的測試工具，它同時也是一個業務人員可以相對輕易掌握的性能測試工具，因此loadrunner內很多名詞解釋也不能單純從技術人員的角度從字面意義上理解。

通常來說，面對同樣100筆業務交易量，普遍會認為100vuser對服務器產生的負載會比50vuser要高，但是在性能腳本能夠在較快的響應時間中完成時，由於50vuser執行過程中每一個vuser都需要發生兩次叠代，導致了性能場景中vuser在腳本action部分停留的時間更長，因此反而能夠得到比100vuser的更高的vuser在線數，更高在線數帶來的也就是更大的負載，也就是說：

同等業務量的情況下，50線程所產生的負載完全有可能比100線程所產生的負載要高。

為了避免發生這種問題，“並發（集合點）”的真正作用就體現出來了，通過集合點函數控制了vuser的行為相對一致，降低了初始化過程和事務前後文請求產生的時間差影響。測試工具中並發存在的真正意義也就在這裏，對集合點所理解的“並發”，和現場實際用戶裏面同時觸發的請求關系不是太大。

分析“並發”需求時的一些典型：

a) 某個業務系統裏面有10000用戶，但是能夠訪問這個系統的終端數只有1000個、或者所需測試的業務每個月上限是1000筆，那麽最高在線用戶數就不可能超過1000、業務量也不可能超過1000。所以，有些時候在分析性能需求的時候，去統計一個業務系統的用戶數還不如去統計能夠訪問這個系統的終端數、甚至業務量靠譜。

b) 某個業務系統裏面，各個業務模塊都不一樣，那麽就是說完成一筆業務交易，所產生的請求數也是不一樣的，例如表單新增，有的需要填寫20個字段，有的只需要填寫5個字段，各個表單都不一樣，那麽為了更接近的去模擬用戶現場負載，請求數都不一樣的各種業務混在一起，並發數又應該是多少呢？

為了解決這些問題，需要首先考慮“並發”的粒度，以真實的業務場景為例：

a) 把粒度控制在用戶上來看，假定所有用戶訪問一次系統平均耗時500秒，一個業務峰值會有800用戶在線，則800/500=1.6。理論上，系統的性能需求是每秒要成功處理1.6個用戶的請求；

b) 把粒度控制在事務上來看，假定所有用戶執行一次完整的、成功的業務操作平均需要500秒，一個業務峰值有2000筆所關註的業務需要去執行，則2000/500=4。理論上，系統的性能需求是每秒要成功處理4筆業務交易；

c) 把粒度控制在請求上來看，假定所有用戶執行一次完整的、不管成功或者失敗的HTTP請求操作平均需要0.08秒，一個業務峰值有28000個請求需要去完成，則28000/0.08=350000。理論上，系統的性能需求是每秒要成功處理350000個請求。

實際一點的案例看看

在下面的圖表中，橫軸表示了某業務系統中上午9：00至12：00的一個區間，假定期間只有A、B、C訪問了該業務系統。如果用戶的訪問過程中發送一個請求，則在請求發生的時間中標識一個點，由圖可見：

A用戶的行為：早上9：00訪問了業務系統，並發生了一連串的請求（多個點已經連成一條直線），再然後沒有再連續的發生請求（沒有再出現黑線），而是有規律的間歇請求，我們暫且猜想用戶A這個時候在瀏覽系統中的業務數據，這確實也符合瀏覽行為，空白階段可以理解為在線的瀏覽，並不會對服務器產生負載；

B用戶的行為：早上9：00訪問了業務系統，並在臨近12：00訪問了業務系統，發送了一連串的請求，我們猜想該用戶在執行了一些業務操作，瀏覽所占的比例比較低；

C用戶的行為：僅僅在10：30左右訪問了業務系統，執行了一連串業務操作以後沒有再訪問系統。

那麽在這裏案例裏面，我們已知：3用戶在線。問題：並發用戶最高該是多少？答案其實顯而易見，並發只有2個用戶，因為用戶C執行的業務操作的同時只有A也在執行業務操作，B完全是不在線。

還會有人認為100用戶在線就應該上100個vuser/線程麽？

關於性能測試中“並發”的解釋