內容參考：構建高性能WEB站點.pdf
一、吞吐率
我們一般使用單位時間內服務器處理的請求數來描述其並發處理能力。稱之為吞吐率（Throughput），單位是"req/s"。吞吐率特指WEB服務器單位時間內處理的請求數。
另一種描述，吞吐率是單位時間內網絡上傳輸的數據量，也可以指單位時間內處理客戶請求數量。它是衡量網絡性能的重要指標。通常情況下，吞吐率用“字節數/秒”來衡量。當然你也可以用“請求數/秒”和“頁面數/秒”來衡量。其實不管一個請求還是一個頁面，它的本質都是在網絡上傳輸的數據，那么用來表述數據的單位就是字節數。
二、吞吐量
吞吐量，是指在一次性能測試過程中網絡上傳輸的數據量的總和。
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，在容量規划的測試中，吞吐量是一個重點關注的指標，因為它能夠說明系統級別的負載能力，另外，在性能調優過程中，吞吐量指標也有重要的價值。如一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些誇張，但我想說明的是這個運輸能力是整個系統的瓶頸。
提示，用吞吐量來衡量一個系統的輸出能力是極其不准確的，用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鍾，流出0.1噸水。當然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力比10個水龍頭的強嗎？所以，我們要加單位時間，看誰1秒鍾的出水量大，即吞吐率。
三、事務，TPS(Transaction Per Second)
就是用戶某一步或幾步操作的集合。不過，我們要保證它有一個完整意義。比如用戶對某一個頁面的一次請求，用戶對某系統的一次登錄，淘寶用戶對商品的一次確認支付過程。這些我們都可以看作一個事務。那么如何衡量服務器對事務的處理能力。又引出一個概念：
TPS:每秒鍾系統能夠處理事務或交易的數量
它是衡量系統處理能力的重要指標。一個 事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
TPS包括了：1）用戶請求服務器；2）服務器自己的內部處理；3）服務器返回給用戶
這三個過程，每秒能夠完成N個這三個過程，則TPS就為N。
點擊率可以看作是TPS的一種特定情況。點擊率更能體現用戶端對服務器的壓力。TPS更能體現服務器對客戶請求的處理能力。
每秒鍾用戶向web服務器提交的HTTP請求數。這個指標是web應用特有的一個指標；web應用是“請求-響應”模式，用戶發一個申請，服務器就要處理一次，所以點擊是web應用能夠處理的交易的最小單位。如果把每次點擊定義為一個交易，點擊率和TPS就是一個概念。容易看出，點擊率越大，對服務器的壓力也就越大，點擊率只是一個性能參考指標，重要的是分析點擊時產生的影響。
需要注意的是，這里的點擊不是指鼠標的一次“單擊”操作，因為一次“單擊”操作中，客戶端可能向服務器發送多個HTTP請求。
四、吞吐量、吞吐率的意義
- 吞吐量的限制是性能瓶頸的一種重要表現形式，因此，有針對地對吞吐量設計測試，可以協助盡快定位到性能瓶頸所在的位置
- 80%系統的性能瓶頸都是由吞吐量制約的
- 並發用戶和吞吐量瓶頸之間存在一定的關聯
- 通過不斷增加並發用戶數和吞吐量來觀察系統的性能瓶頸。然后，從網絡、數據庫、應用服務器和代碼本身4個環節來確定
五、吞吐率和壓力測試
單從定義來看，吞吐率描述了服務器在實際運行期間單位時間內處理的請求數，然而，我們更加關心的是服務器並發處理能力的上限，也就是單位時間內服務器能夠處理的最大請求數，即最大吞吐率。
所以我們普遍使用“壓力測試”的方法，通過模擬足夠多數目的並發用戶，分別持續發送一定的HTTP請求，並統計測試持續的總時間，計算出基於這種“壓力”下的吞吐率，即為一個平均計算值。
！！注意
- 在Web服務器的實際工作中，其處理的HTTP請求通常包括對很多不同資源的請求，也就是請求不同的URL，比如這些請求有的是獲取圖片，有的是獲取動態內容，顯然服務器處理這些請求所花費的時間各不相同，而這些請求在不同時間的組成比例又是不確定的。這就是實際情況下的吞吐率。
- 所以，我們對於同一個特定有代表性的請求進行壓力測試，然后對多個請求的吞吐率按照比例計算加權平均值。
- Web服務器並發能力強弱的關鍵便是在於如何計算針對不同的請求性質來設計最優並發策略。在一定程度上使得Web服務器的性能無法充分發揮，這很容易理解，就像銀行對不同業務設立不同的窗口一樣，這些窗口的職員分別熟悉自己的窗口業務。可以為不同的客戶分別快速辦理業務，但是如果讓這些窗口都可以辦理所有業務，也就是客戶可以去任何窗口辦理任何業務，那會是怎么樣呢？沒有幾個銀行業務員會對所有業務都輕車熟路，這樣勢必會影響到整體的業務辦理速度。
六、壓力測試的前提
吞吐率性能測試的前提
- 並發用戶數
- 總請求數
- 請求資源描述
壓力測試的描述一般包括兩個部分，即並發用戶數和總請求數，也就是模擬多少用戶同時向服務器發送多少請求。請求性質則是對請求的URL所代表的的資源的描述，比如1KB大小的靜態文件，或者包含10次數據庫查詢的動態內容等。
1、並發用戶數
並發用戶數就是指在某一時刻同時向服務器發送請求的用戶總數。
假如100個用戶同時向服務器分別進行10次請求，與1個用戶向服務器連續進行1000次請求。兩個效果一樣么？也就是說給服務器帶來的壓力一樣嗎？
雖然看起來服務器都需要連續處理1000個請求，其實關鍵的區別就在於，是否真的“連續”。首先有一點需要明白，對於壓力測試中提到的一個每一個用戶，連續發送請求實際上是指在發送一個請求並接收到響應數據后再發送下一個請求。這樣一來，從微觀層面來看，1個用戶向服務器連續進行1000次請求的過程中，任何時刻服務器的網卡緩存區中只有來自該用戶的1個請求，而100個用戶同時向服務器進行10次請求的過程中，服務器網卡接收緩沖區中最多有100個等待處理的請求，顯然這時候服務器的壓力更大。
經常有人說某個Web服務器能支持多少並發數，除此之外沒有任何上下文，這讓很多人摸不着頭腦，人們常常把並發用戶數和吞吐率混淆，他們並不是一回事。通過前面的介紹，我們很清楚，吞吐率是指在一定並發用戶數的情況下，服務器處理請求能力的量化體現。
如下例子：
我們可以說，這個櫃台支持的最大並發數為10，因為恰好在這個並發數下，櫃台業務開展的非常成功。顧客們都對服務時間非常滿意，而此時代表業務辦理次數的櫃台吞吐率也比較高，商場和顧客們實現雙贏。
可見，通常所講的最大並發數是有一定利益前提的，那就是服務器和用戶雙方所期待的最大收益，服務器希望支持高並發及高吞吐量，而用戶不管那么多，只希望等待較少的時間，或者得到更快的下載速度。
所以得出最大並發數的意義，在於了解服務器的承載能力，並且結合用戶規模考慮適當的擴展方案。
對於同一域名下URL的並發下載數是有最大限制的，具體限制視瀏覽器的不同而不同。一個真實的用戶可能會給服務器帶來兩個或更多的並發用戶的壓力，一些高明的用戶還可以通過一些方法來修改瀏覽器的並發數限制。
2、請求等待時間
- 用戶平均請求等待時間
- 服務器平均請求處理時間
首先，假設並發用戶數為1，也就是只有一個用戶在向服務器源源不斷地發送請求，那么每個請求的等待時間也就是它的處理時間，等於總時間除以總請求數，這時用戶平均請求等待時間和服務器平均請求處理時間是相同的，這很容易理解。
然后，假設並發用戶數為100，那么便會有100個用戶同時向服務器發送請求，簡單地說，這時Web服務器一般會采用多進程或多線程的並發模型，通過多個執行流來同時處理多個並發用戶的請求，而多執行流體系的設計原則便是輪流交錯使用CPU時間片，所以每個執行流花費的時間都被拉長。對每個用戶而言，每個請求的平均等待時間必然增加；而對於服務器而言，如果並發策略得當，每個請求的平均處理時間可能減少。
所以，這兩個時間的本質在於，用戶平均請求等待時間主要用於衡量服務器在一定並發用戶數的情況下，對於單個用戶的服務質量；而服務器平均請求處理時間與前者相比，則用戶衡量服務器的整體服務質量，它其實就是吞吐率的倒數。
七、總結
針對吞吐量、吞吐率、TPS的測試，都需要指明單位時間。
以上測試忽略服務器硬件配置，所以性能測試結果也不側重於它的絕對值意義，我們的目的是探討如何測量性能以及如何根據不同的場景來優化性能。
以上測試使用硬件為
CPU： Intel(R) Xeon(R) CPU 1.60GHz 內存：4GB 硬盤轉速： 15kr/min
以上幾個指標的測試，主要是為了提升服務器的處理效率，為構建高可用的Web站點做准備。
轉載自《構建高性能WEB站點之 吞吐率、吞吐量、TPS、性能測試》