吞吐率、吞吐量、TPS、性能測試，紙上不談兵----一步一步構建高性能 Web 站點

1、吞吐率

咱們通常使用單位時間內服務器處理的請求數來描述其併發處理能力。稱之爲吞吐率（Throughput），單位是 「req/s」。吞吐率特指Web服務器單位時間內處理的請求數。

好比Apache 的 mod_status 模塊提供的以下統計

 

另外一種描述，吞吐率是，單位時間內網絡上傳輸的數據量，也能夠指單位時間內處理客戶請求數量。它是衡量網絡性能的重要指標。一般狀況下，吞吐率「字節數/秒」來衡量。固然你也能夠用「請求數/秒」和「頁面數/秒」來衡量。其實無論一個請求仍是一個頁面，它的本質都是在網絡上傳輸的數據，那麼用來表述數據的單位就是字節數。

2、吞吐量

吞吐量，是指在一次性能測試過程當中網絡上傳輸的數據量的總和。

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

　　提示，用吞吐量來衡量一個系統的輸出能力是極其不許確的，用個最簡單的例子說明，一個水龍頭開一天一晚上，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。固然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力是10個水龍頭的強？因此，咱們要加單位時間，看誰1秒鐘的出水量大。這就是吞吐率。

3、事務，TPS(Transaction Per second)

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

每秒鐘系統可以處理事務或交易的數量，它是衡量系統處理能力的重要指標。

點擊率能夠看作是TPS的一種特定狀況。點擊率更能體現用戶端對服務器的壓力。TPS更能體現服務器對客戶請求的處理能力。

每秒鐘用戶向web服務器提交的HTTP請求數。這個指標是web 應用特有的一個指標；web應用是「請求-響應」模式，用戶發一個申請，服務器就要處理一次，因此點擊是web應用可以處理的交易的最小單位。若是把每次點擊定義爲一個交易，點擊率和TPS就是一個概念。容易看出，點擊率越大。對服務器的壓力也越大，點擊率只是一個性能參考指標，重要的是分析點擊時產生的影響。

須要注意的是，這裏的點擊不是指鼠標的一次「單擊」操做，由於一次「單擊」操做中，客戶端可能向服務器發現多個HTTP請求。

4、吞吐量、吞吐率的意義

• 吞吐量的限制是性能瓶頸的一種重要表現形式，所以，有針對地對吞吐量設計測試，能夠協助儘快定位到性能冰晶所在的位置
• 80%系統的性能瓶頸都是由吞吐量制約
• 併發用戶和吞吐量瓶頸之間存在必定的關聯
• 經過不斷增長併發用戶數和吞吐量觀察系統的性能瓶頸。而後，從網絡、數據庫、應用服務器和代碼自己4個環節肯定系統的性能瓶頸。

5、吞吐率和壓力測試

單從定義來看，吞吐率描述了服務器在實際運行期間單位時間內處理的請求數，然而，咱們更加關心的是服務器併發處理能力的上限，也就是單位時間內服務器可以處理的最大請求數，即最大吞吐率。

因此咱們廣泛使用「壓力測試」的方法，經過模擬足夠多數目的併發用戶，分別持續發送必定的HTTP請求，並統計測試持續的總時間，計算出基於這種「壓力」下的吞吐率，即爲一個平均計算值

！！注意

• 在Web服務器的實際工做中，其處理的HTTP請求一般包括對不少不一樣資源的請求，也就是請求不一樣的URL，
  好比這些請求有的是獲取圖片，有的是獲取動態內容，顯然服務器處理這些請求所花費的時間各不相同，而這些請求的不一樣時間組成比例又是不肯定的。這就是實際狀況下的吞吐率。

• 因此，咱們 對於同一個特定有表明性的請求進行壓力測試，而後對多個請求的吞吐率按照比例計算加權平均值。

• Web服務器併發能力強弱的關鍵即是在於如何計算針對不一樣的請求性質來設計最優併發策略。在必定程度上使得Web服務器的性能沒法充分發揮，這很容易理解，就像銀行對不一樣業務設立不一樣的窗口同樣，這些窗口的服務員分別熟悉本身的窗口業務。能夠未不一樣的客戶分別快速辦理業務，可是若是讓這些窗口均可以辦理全部業務，也就是客戶能夠去任何窗口辦理任何業務，那會是怎麼樣呢？沒有幾個銀行業務員會對全部業務都輕車熟路，這樣勢必會影響到總體的業務辦理速度。

6、壓力測試的前提

吞吐率性能測試的前提

• 併發用戶數
• 總請求數
• 請求資源描述

壓力測試的描述通常包括兩個部分，即併發用戶數和總請求數，也就是模擬多少用戶同時向服務器發送多少請求。

請求性質則是對請求的URL所表明的資源的描述，好比1KB大小的靜態文件，或者包含10次數據庫查詢的動態內容等。

一、 併發用戶數

併發用戶數就是指在某一時刻同時向服務器發送請求的用戶總數。

假如100個用戶同時向服務器分別進行10次請求，與1個用戶向服務器連續進行1000次請求。兩個的效果同樣麼？

一個用戶向服務器連續進行1000次請求的過程當中，任什麼時候刻服務器的網卡接受緩存區中只有來自該用戶的1個請求，而100個用戶同時向服務器分別進行10次請求的過程當中，服務器網卡接收緩衝區中最多有100個等待處理的請求，顯然這時候服務器的壓力更大。

常常有人說某個Web服務器能支持多少併發數，除此以外沒有任何上下文，這讓不少人摸不着頭腦，人們經常把併發用戶數和吞吐率混淆，他們並非一回事。

一個服務器最多支持多少併發用戶數呢？

 

咱們能夠說，這個櫃檯支持的最大併發數爲10，由於剛好在這個併發數下，櫃檯業務開展的很是成功。顧客們都對服務時間很是滿意，而此時表明業務辦理次數的櫃檯吞吐率也比較高，商場和顧客們實現共贏。

可見，一般所講的最大併發數是有必定利益前提的，那就是服務器和用戶雙方所期待的最大收益，服務器但願支持高併發數及高吞吐率，而用戶無論那麼多，只但願等待較少的時間，或者獲得更快的下載速度。

因此得出最大併發數的意義，在於瞭解服務器的承載能力，而且結合用戶規模考慮適當的擴展方案。

對於同一域名下URL的併發下載數是有最大限制的，具體限制視瀏覽器的不一樣而不一樣。
一個真實的用戶可能會給服務器帶來兩個或更多的併發用戶的壓力，一些高明的用戶還能夠經過一些方法來修改瀏覽器的併發數限制。

 

 

二、請求等待時間

• 用戶平均請求等待時間
• 服務器平均請求處理時間

用戶平均請求等待時間主要用戶衡量服務器在必定併發用戶數的狀況下，對於單個用戶的服務質量
服務器平均請求處理時間與前者相比，則用戶衡量服務器的總體服務質量，它其實就是吞吐率的倒數。

7、壓力測試

Apache 附帶的ab，ab能夠直接在web服務器本地發起測試請求。

 

一、吞吐率隨併發用戶數變化的曲線圖

 

二、服務器平均請求處理時間隨併發用戶數變化的曲線圖

當併發用戶數超過150 以後，請求的平均等待時間大幅度增長，當併發用戶達到200後，等待時間開始急劇增長。

 

三、用戶平均請求等待時間隨併發用戶數變化的曲線圖

 

8、總結

針對，吞吐量，吞吐率，TPS的測試，都須要指明單位時間。

以上測試忽略服務器硬件配置，因此性能測試結果也不側重於它的絕對值意義，咱們的目的是探討如何測量性能以及如何根據不一樣的場景來優化性能。

以上測試使用硬件爲

CPU： Intel(R) Xeon(R) CPU 1.60GHz
內存：4GB
硬盤轉速： 15kr/min

以上幾個指標的測試，主要是爲了提高服務器的處理效率，爲構建高可用的Web站點作準備。

9、下期內容

影響 吞吐量，吞吐率，TPS指標的因素，除了服務器的硬件配置，就剩下併發策略了。

簡單地說，併發策略的設計就是在服務器同時處理較多請求的時候，如何合理協調並充分利用CPU計算和I/O請求，使其在較大併發用戶數的狀況下提供較高的吞吐率

並不存在一個對全部性質的請求都高效的併發策略