一、吞吐率
我們一般使用單位時間內服務器處理的請求數來描述其并發處理能力。稱之為吞吐率（Throughput），單位是 “req/s”。吞吐率特指Web服務器單位時間內處理的請求數。
比如Apache 的 mod_status 模塊提供的如下統計
另一種描述，吞吐率是，單位時間內網絡上傳輸的數據量，也可以指單位時間內處理客戶請求數量。它是衡量網絡性能的重要指標。通常情況下，吞吐率“字節數/秒”來衡量。當然你也可以用“請求數/秒”和“頁面數/秒”來衡量。其實不管一個請求還是一個頁面，它的本質都是在網絡上傳輸的數據，那么用來表述數據的單位就是字節數。
二、吞吐量
吞吐量，是指在一次性能測試過程中網絡上傳輸的數據量的總和。
對于交互式應用來說，吞吐量指標反映的是服務器承受的壓力，在容量規劃的測試中，吞吐量是一個重點關注的指標，因為它能夠說明系統級別的負載能力，另外，在性能調優過程中，吞吐量指標也有重要的價值。如一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些夸張，但我想說明的是這個運輸能力是整個系統的瓶頸。
提示，用吞吐量來衡量一個系統的輸出能力是極其不準確的，用個最簡單的例子說明，一個水龍頭開一天一夜，流出10噸水；10個水龍頭開1秒鐘，流出0.1噸水。當然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力是10個水龍頭的強？所以，我們要加單位時間，看誰1秒鐘的出水量大。這就是吞吐率。
三、事務，TPS(Transaction Per second)
就是用戶某一步或幾步操作的集合。不過，我們要保證它有一個完整意義。比如用戶對某一個頁面的一次請求，用戶對某系統的一次登錄，淘寶用戶對商品的一次確認支付過程。這些我們都可以看作一個事務。那么如何衡量服務器對事務的處理能力。又引出一個概念----TPS
每秒鐘系統能夠處理事務或交易的數量，它是衡量系統處理能力的重要指標。
點擊率可以看做是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個請求，而100個用戶同時向服務器分別進行10次請求的過程中，服務器網卡接收緩沖區中最多有100個等待處理的請求，顯然這時候服務器的壓力更大。
經常有人說某個Web服務器能支持多少并發數，除此之外沒有任何上下文，這讓很多人摸不著頭腦，人們常常把并發用戶數和吞吐率混淆，他們并不是一回事。
一個服務器最多支持多少并發用戶數呢？
我們可以說，這個柜臺支持的最大并發數為10，因為恰好在這個并發數下，柜臺業務開展的非常成功。顧客們都對服務時間非常滿意，而此時代表業務辦理次數的柜臺吞吐率也比較高，商場和顧客們實現雙贏。
可見，通常所講的最大并發數是有一定利益前提的，那就是服務器和用戶雙方所期待的最大收益，服務器希望支持高并發數及高吞吐率，而用戶不管那么多，只希望等待較少的時間，或者得到更快的下載速度。
所以得出最大并發數的意義，在于了解服務器的承載能力，并且結合用戶規模考慮適當的擴展方案。
對于同一域名下URL的并發下載數是有最大限制的，具體限制視瀏覽器的不同而不同。
一個真實的用戶可能會給服務器帶來兩個或更多的并發用戶的壓力，一些高明的用戶還可以通過一些方法來修改瀏覽器的并發數限制。
2、請求等待時間
- 用戶平均請求等待時間
- 服務器平均請求處理時間
用戶平均請求等待時間主要用戶衡量服務器在一定并發用戶數的情況下，對于單個用戶的服務質量
服務器平均請求處理時間與前者相比，則用戶衡量服務器的整體服務質量，它其實就是吞吐率的倒數。
七、壓力測試
Apache 附帶的ab，ab可以直接在web服務器本地發起測試請求。
1、吞吐率隨并發用戶數變化的曲線圖
2、服務器平均請求處理時間隨并發用戶數變化的曲線圖
當并發用戶數超過150 之后，請求的平均等待時間大幅度增加，當并發用戶達到200后，等待時間開始急劇增加。
3、用戶平均請求等待時間隨并發用戶數變化的曲線圖
八、總結
針對，吞吐量，吞吐率，TPS的測試，都需要指明單位時間。
以上測試忽略服務器硬件配置，所以性能測試結果也不側重于它的絕對值意義，我們的目的是探討如何測量性能以及如何根據不同的場景來優化性能。
以上測試使用硬件為
CPU： Intel(R) Xeon(R) CPU 1.60GHz
內存：4GB
硬盤轉速： 15kr/min
以上幾個指標的測試，主要是為了提升服務器的處理效率，為構建高可用的Web站點做準備。
九、下期內容
影響 吞吐量，吞吐率，TPS指標的因素，除了服務器的硬件配置，就剩下并發策略了。
簡單地說，并發策略的設計就是在服務器同時處理較多請求的時候，如何合理協調并充分利用CPU計算和I/O請求，使其在較大并發用戶數的情況下提供較高的吞吐率
并不存在一個對所有性質的請求都高效的并發策略
如需知道更多，請聽下回分解。
參考：
