效能測試基礎（四）吞吐量

我們每天的生活中都在用水用電，如果我們把水龍頭擰到最大，還是一滴水不出。那我們就會找物業/房東去詢問情況，但一般不會想過去找自來水公司解決。我們每天都會上網，看電影很卡，需要等很久才緩衝一個幾幀；開啟網頁很慢，IE狀態條一直50%，那我們就會找電信伺服器商，而不是某視訊網站的客服。

以上的情況是正常的，這是生活常識。我想說明的是，你可能從來不關心一個自來水廠供應多少水，但供應多少水對一個自來廠來說卻非常重要。你也可能從來不關心一個系統的吞吐量，但吞吐量對一個系統來說卻非常重要。

吞吐量

指在一次效能測試過程中網路上傳輸的資料量的總和。

對於互動式應用來說，吞吐量指標反映的是伺服器承受的壓力，在容量規劃的測試中，吞吐量是一個重點關注的指標，因為它能夠說明系統級別的負載能力，另外，在效能調優過程中，吞吐量指標也有重要的價值。如一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些誇張，但我想說明的是這個運輸能力是整個系統的瓶頸。

但是，用吞吐量來衡量一個系統的輸出能力是極其不準確的，用個最簡單的例子說明，一個水龍頭開24小時，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。當然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力遠超10個水龍頭？所以，我們要加單位時間的限制，每秒/出水量，這就引出了一個新的概念–吞吐率。

吞吐率

單位時間內網路上傳輸的資料量，也可以指單位時間內處理客戶請求數量。它是衡量網路效能的重要指標，通常情況下，吞吐率用“位元組數/秒”來衡量，當然，你可以用“請求數/秒”和“頁面數/秒”來衡量。其實，不管是一個請求還是一個頁面，它的本質都是在網路上傳輸的資料，那麼來表示資料的單位就是位元組數。

但是從業務的角度看，吞吐率也可以用“業務數/小時”、“訪問人數/小時”、“頁面訪問量/小時”來衡量。例如，在銀行卡審批系統中，可以用“千件/小時”來衡量系統的業務處理能力。那麼，從使用者的角度，一個表單提交可以得到一次審批。這又引出來一個概念—事務。

事務

就是使用者某一步或幾步操作的集合。不過，我們要保證它有一個完整意義。比如使用者對某一個頁面的一次請求，對某系統的一次登入，對商品的一次確認支付過程。這些我們都可以看作一個事務。那麼如何衡量伺服器對事務的處理能力。又引出一個概念----TPS

TPS (Transaction Per second)
每秒鐘系統能夠處理事務或交易的數量，它是衡量系統處理能力的重要指標。

點選率（Hit Per Second）
點選率可以看做是TPS的一種特定情況。點選率更能體現使用者端對伺服器的壓力。TPS更能體現伺服器對客戶請求的處理能力。

每秒鐘使用者向Web伺服器提交的HTTP請求數。這個指標是Web 應用特有的一個指標；Web應用是“請求—響應”模式，使用者發一個申請，伺服器就要處理一次，所以點選是Web應用能夠處理的交易的最小單位。如果把每次點選定義為一個交易，點選率和TPS就是一個概念。容易看出，點選率越大。對伺服器的壓力也越大，點選率只是一個效能參考指標，重要的是分析點選時產生的影響。

需要注意的是，這裡的點選不能簡單的看作滑鼠的一次“單擊”操作，也許一次“單擊”操作中，客戶端可能向伺服器發現多個HTTP請求。

吞吐量指標的作用：

再次將話題迴歸到吞吐量上，在我們的效能測試中檢視吞吐量對我們的測試有什麼意義呢。

1. 用於協助設計效能測試場景，以及衡量效能測試場景是否達到了預期的設計目標：在設計效能測試場景時，吞吐量可被用於協助設計效能測試場景，根據估算的吞吐量資料，可以對應到測試場景的事務發生頻率，事務發生次數等；另外，在測試完成後，根據實際的吞吐量可以衡量測試是否達到了預期的目標。

2. 用於協助分析效能瓶頸：吞吐量的限制是效能瓶頸的一種重要表現形式，因此，有針對性地對吞吐量設計測試，可以協助儘快定位到效能瓶頸的所在位置。

擴充套件：

RBI（rapid bottleneck identify）

是Empirix公司提出的快速識別系統效能瓶頸的方法。該方法基於以下事實。

1. 發現的80%系統的效能瓶頸都由吞吐量制約；

2. 併發使用者數和吞吐量瓶頸之間存在一定的關聯；

3. 採用吞吐量測試可以更快速定位問題。 

通過不斷增加併發使用者數和吞吐量觀察系統的效能瓶頸。然後，從網路、資料庫、應用伺服器和程式碼本身4個環節確定系統的的效能瓶頸。