一、吞吐率
我們一般使用單位時間內服務器處理的請求數來描述其併發處理能力。稱之爲吞吐率（Throughput），單位是 “req/s”。吞吐率特指Web服務器單位時間內處理的請求數。
另一種描述，吞吐率是，單位時間內網絡上傳輸的數據量，也可以指單位時間內處理客戶請求數量。它是衡量網絡性能的重要指標。通常情況下，吞吐率“字節數/秒”來衡量。當然你也可以用“請求數/秒”和“頁面數/秒”來衡量。其實不管一個請求還是一個頁面，它的本質都是在網絡上傳輸的數據，那麼用來表述數據的單位就是字節數。
二、吞吐量
吞吐量，是指在一次性能測試過程中網絡上傳輸的數據量的總和。
對於交互式應用來說，吞吐量指標反映的是服務器承受的壓力，在容量規劃的測試中，吞吐量是一個重點關注的指標，因爲它能夠說明系統級別的負載能力，另外，在性能調優過程中，吞吐量指標也有重要的價值。如一個大型工廠，他們的生產效率與生產速度很快，一天生產10W噸的貨物，結果工廠的運輸能力不行，就兩輛小型三輪車一天拉2噸的貨物，比喻有些誇張，但我想說明的是這個運輸能力是整個系統的瓶頸。
三、事務，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、請求等待時間
- 用戶平均請求等待時間
- 服務器平均請求處理時間
用戶平均請求等待時間主要用戶衡量服務器在一定併發用戶數的情況下，對於單個用戶的服務質量 服務器平均請求處理時間與前者相比，則用戶衡量服務器的整體服務質量，它其實就是吞吐率的倒數。
八、總結
針對，吞吐量，吞吐率，TPS的測試，都需要指明單位時間。
以上測試忽略服務器硬件配置，所以性能測試結果也不側重於它的絕對值意義，我們的目的是探討如何測量性能以及如何根據不同的場景來優化性能。
以上測試使用硬件爲
CPU： Intel(R) Xeon(R) CPU 1.60GHz 內存：4GB 硬盤轉速： 15kr/min
以上幾個指標的測試，主要是爲了提升服務器的處理效率，爲構建高可用的Web站點做準備。