性能測試知多少---吞吐量

　　我們每天的生活中都在用水用電，我隻會關心自己的水管是否有水，水壓是否穩定，如果我們把水龍頭擰到最大，還是一滴一滴

的流水。那我們就要憤怒了，直接找房東問明情況。我們從來沒想過去找自來水公司。我們每天都會上網，網速很慢，看個電影很卡，需要等很久才緩沖一個畫面，

我們打開網頁很慢，ie狀态條一直50%，那我們就要憤怒了，直接找電信、網通公司問明情況。

　　我想說以上的情況是正常的，如果你在優酷上看視訊，需要緩沖很久。然後，你跟優酷客服打電話；通路部落格園網站半天打不開，就跟dudu打電話，那我們如果不是對網絡一竅不通的白癡，那一定是腦抽了。其實，我想說明的是，你可能從來不關心一個自來水廠供應多少水，但供應多少水對一個自來廠來說卻非常重要。你可能從來不關心一個系統的吞吐量，但吞吐量對一個系統來說卻非常重要。

ps:依照個人慣例，純文字的内容必須配一張淡疼的圖檔！^_^

吞吐量

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

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

　　提示，用吞吐量來衡量一個系統的輸出能力是極其不準确的，用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。當然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力是10個水龍頭的強？是以，我們要加機關時間，看誰1秒鐘的出水量大。這就是吞吐率。

吞吐率

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

　　不過以不同的方式表達的吞吐量可以說明不同層次的問題。例如，以位元組數/秒方式表示的吞吐量主要受網絡基礎設定、伺服器架構、應用伺服器制約；以請求數/秒方式表示的吞吐量主要受應用伺服器和應用代碼的制約。

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

事務

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

　　其實，我講了這麼多概念，我們無非是站在不同的角度去分解系統的性能，站在使用者的角度，伺服器的角度、系統的各種角度。了解一個人需要多方面，了解一個系統也需要多方面。我在盡量把這些東西講的不枯燥，而且易懂。其實，自己寫的過程也是思考的過程。