咱們天天的生活中都在用水用電,我只會關心本身的水管是否有水,水壓是否穩定,若是咱們把水龍頭擰到最大,仍是一滴一滴的流水。那咱們就要憤怒了,直接找房東問明狀況。咱們歷來沒想過去找自來水公司。咱們天天都會上網,網速很慢,看個電影很卡,須要等好久才緩衝一個畫面,咱們打開網頁很慢,IE狀態條一直50%,那咱們就要憤怒了,直接找電信、網通公司問明狀況。
我想說以上的狀況是正常的,若是你在優酷上看視頻,須要緩衝好久。而後,你跟優酷客服打電話;訪問博客園網站半天打不開,就跟dudu打電話,那咱們若是不是對網絡一竅不通的白癡,那必定是腦抽了。其實,我想說明的是,你可能歷來不關心一個自來水廠供應多少水,但供應多少水對一個自來廠來講卻很是重要。你可能歷來不關心一個系統的吞吐量,但吞吐量對一個系統來講卻很是重要。
ps:依照我的慣例,純文字的內容必須配一張淡疼的圖片!^_^
吞吐量
指在一次性能測試過程當中網絡上傳輸的數據量的總和。
對於交互式應用來講,吞吐量指標反映的是服務器承受的壓力,在容量規劃的測試中,吞吐量是一個重點關注的指標,由於它可以說明系統級別的負載能力,另外,在性能調優過程當中,吞吐量指標也有重要的價值。如一個大型工廠,他們的生產效率與生產速度很快,一天生產10W噸的貨物,結果工廠的運輸能力不行,就兩輛小型三輪車一天拉2噸的貨物,比喻有些誇張,但我想說明的是這個運輸能力是整個系統的瓶頸。
提示,用吞吐量來衡量一個系統的輸出能力是極其不許確的,用個最簡單的例子說明,一個水龍頭開一天一晚上,流出10噸水;10個水龍頭開1秒鐘,流出0.1噸水。固然是一個水龍頭的吞吐量大。你能說1個水龍頭的出水能力是10個水龍頭的強?因此,咱們要加單位時間,看誰1秒鐘的出水量大。這就是吞吐率。
吞吐率
單位時間內網絡上傳輸的數據量,也能夠指單位時間內處理客戶請求數量。它是衡量網絡性能的重要指標,一般狀況下,吞吐率用「字節數/秒」來衡量,固然,你能夠用「請求數/秒」和「頁面數/秒」來衡量。其實,不論是一個請求仍是一個頁面,它的本質都是在網絡上傳輸的數據,那麼來表示數據的單位就是字節數。
不過以不一樣的方式表達的吞吐量能夠說明不一樣層次的問題。例如,以字節數/秒方式表示的吞吐量主要受網絡基礎設置、服務器架構、應用服務器制約;以請求數/秒方式表示的吞吐量主要受應用服務器和應用代碼的制約。
可是從業務的角度看,吞吐率也能夠用「業務數/小時或天」、「訪問人數/小時或天」、「頁面訪問量/小時或天」來衡量。例如,在銀行卡審批系統中,能夠用「千件/小時」來衡量系統的業務處理能力。那麼,從用戶的角度,一個表單提交能夠獲得一次審批。又引出來一個概念---事務。
事務web
就是用戶某一步或幾步操做的集合。不過,咱們要保證它有一個完整意義。好比用戶對某一個頁面的一次請求,用戶對某系統的一次登陸,淘寶用戶對商品的一次確認支付過程。這些咱們均可以看做一個事務。那麼如何衡量服務器對事務的處理能力。又引出一個概念----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個環節肯定系統的的性能瓶頸。
其實,我講了這麼多概念,咱們無非是站在不一樣的角度去分解系統的性能,站在用戶的角度,服務器的角度、系統的各類角度。瞭解一我的須要多方面,瞭解一個系統也須要多方面。我在儘可能把這些東西講的不枯燥,並且易懂。其實,本身寫的過程也是思考的過程。