Loadrunner沒有告訴你的——深入淺出性能概念
版權聲明:本文可以被轉載,但是在未經本人許可前,不得用於任何商業用途或其他以盈利為目的的用途。本人保留對本文的一切權利。如需轉載,請在轉載是保留此版權聲明,並保證本文的完整性。也請轉貼者理解創作的辛勞,尊重作者的勞動成果。
作者:陳雷 (Jackei)
郵箱:jackeichan@gmail.com
Blog:http://jackei.cnblogs.com
大概在一年前的一次討論中,我的好友陳華第一次提到了這個模型的最初版本,經過幾次討論後,我們發現經過完善和擴展的「理髮店模型」可以用來幫助我們理解很多性能測試的概念和理論,以及一些測試中遇到的問題。在最近的一次討論後,我決定撰寫一篇文章來專門講述一下這個模型,希望可以幫助大家更好的理解性能測試有關的知識。
不過,在這篇文章中,我將會盡量的只描述模型本身以及相關的一些擴展,而具體如何將這個模型完全同性能測試關聯起來,我不會全部說破,留下足夠的空間讓大家繼續思考和總結,最好也一起來對這個模型做進一步的完善和擴展^_^ 我相信,當大家在思考的過程中有所收穫並有所突破時,那種快感和收穫的喜悅才真的是讓人倍感振奮而且終生難忘的 ^_^
當然,我要說明的是,這個模型僅僅是1個模型,它與大家實際工作中遇到的各式各樣的情況未必都可以一一對應,但是大的方向和趨勢應該是一致的。
理髮店模型
進一步理解「最佳並發用戶數」和「最大並發用戶數」
理髮店模型的進一步擴展
相關資料
相信大家都進過或見過理髮店,一間或大或小的鋪面,1個或幾個理髮師,幾張理髮用的椅子和供顧客等待的長條板凳。
在我們的這個理髮店中,我們事先做了如下的假設:
1.理髮店共有3名理髮師;
2.每位理髮師剪一個發的時間都是1小時;
3.我們顧客們都是很有時間觀念的人而且非常挑剔,他們對於每次光顧理髮店時所能容忍的等待時間+剪髮時間是3小時,而且等待時間越長,顧客的滿意度越低。如果3個小時還不能剪完頭髮,我們的顧客會立馬生氣的走人。
通過上面的假設我們不難想像出下面的場景:
1.當理髮店內只有1位顧客時,只需要有1名理髮師為他提供服務,其他兩名理髮師可能繼續等著,也可能會幫忙打打雜。1小時後,這位顧客剪完頭髮出門走了。那麼在這1個小時里,整個理髮店只服務了1位顧客,這位顧客花費在這次剪髮的時間是1小時;
2.當理髮店內同時有兩位顧客時,就會同時有兩名理髮師在為顧客服務,另外1位發獃或者打雜幫忙。仍然是1小時後,兩位顧客剪完頭髮出門。在這1小時里,理髮店服務了兩位顧客,這兩位顧客花費在剪髮的時間均為1小時;
3.很容易理解,當理髮店內同時有三位顧客時,理髮店可以在1小時內同時服務三位顧客,每位顧客花費在這次剪髮的時間仍然是均為1小時;
從上面幾個場景中我們可以發現,在理髮店同時服務的顧客數量從1位增加到3位的過程中,隨著顧客數量的增多,理髮店的整體工作效率在提高,但是每位顧客在理髮店內所呆的時間並未延長。
當然,我們可以假設當只有1位顧客和2位顧客時,空閑的理髮師可以幫忙打雜,使得其他理髮師的工作效率提高,並使每位顧客的剪髮時間小於1小時。不過即使根據這個假設,雖然隨著顧客數量的增多,每位顧客的服務時間有所延長,但是這個時間始終還被控制在顧客可接受的範圍之內,並且顧客是不需要等待的。
不過隨著理髮店的生意越來越好,顧客也越來越多,新的場景出現了。假設有一次顧客A、B、C剛進理髮店準備剪髮,外面一推門又進來了顧客D、E、F。因為A、B、C三位顧客先到,所以D、E、F三位只好坐在長板凳上等著。1小時後,A、B、C三位剪完頭髮走了,他們每個人這次剪髮所花費的時間均為1小時。可是D、E、F三位就沒有這麼好運,因為他們要先等A、B、C三位剪完才能剪,所以他們每個人這次剪髮所花費的時間均為2小時——包括等待1小時和剪髮1小時。
通過上面這個場景我們可以發現,對於理髮店來說,都是每小時服務三位顧客——第1個小時是A、B、C,第二個小時是D、E、F;但是對於顧客D、E、F來說,「響應時間」延長了。如果你可以理解上面的這些場景,就可以繼續往下看了。
在新的場景中,我們假設這次理髮店裡一次來了9位顧客,根據我們上面的場景,相信你不難推斷,這9位顧客中有3位的「響應時間」為1小時,有3位的「響應時間」為2小時(等待1小時+剪髮1小時),還有3位的「響應時間」為3小時(等待2小時+剪髮1小時)——已經到達用戶所能忍受的極限。假如在把這個場景中的顧客數量改為10,那麼我們已經可以斷定,一定會有1位顧客因為「響應時間」過長而無法忍受,最終離開理髮店走了。
我想並不需要特別說明,大家也一定可以把上面的這些場景跟性能測試掛上鉤了。如果你還是覺得比較抽象,繼續看下面的這張圖 ^_^
這張圖中展示的是1個標準的軟體性能模型。在圖中有三條曲線,分別表示資源的利用情況(Utilization,包括硬體資源和軟體資源)、吞吐量(Throughput,這裡是指每秒事務數)以及響應時間(Response Time)。圖中坐標軸的橫軸從左到右表現了並發用戶數(Number of Concurrent Users)的不斷增長。
在這張圖中我們可以看到,最開始,隨著並發用戶數的增長,資源佔用率和吞吐量會相應的增長,但是響應時間的變化不大;不過當並發用戶數增長到一定程度後,資源佔用達到飽和,吞吐量增長明顯放緩甚至停止增長,而響應時間卻進一步延長。如果並發用戶數繼續增長,你會發現軟硬體資源佔用繼續維持在飽和狀態,但是吞吐量開始下降,響應時間明顯的超出了用戶可接受的範圍,並且最終導致用戶放棄了這次請求甚至離開。
根據這種性能表現,圖中劃分了三個區域,分別是Light Load(較輕的壓力)、Heavy Load(較重的壓力)和Buckle Zone(用戶無法忍受並放棄請求)。在Light Load和Heavy Load 兩個區域交界處的並發用戶數,我們稱為「最佳並發用戶數(The Optimum Number of Concurrent Users)」,而Heavy Load和Buckle Zone兩個區域交界處的並發用戶數則稱為「最大並發用戶數(The Maximum Number of Concurrent Users)」。
當系統的負載等於最佳並發用戶數時,系統的整體效率最高,沒有資源被浪費,用戶也不需要等待;當系統負載處於最佳並發用戶數和最大並發用戶數之間時,系統可以繼續工作,但是用戶的等待時間延長,滿意度開始降低,並且如果負載一直持續,將最終會導致有些用戶無法忍受而放棄;而當系統負載大於最大並發用戶數時,將註定會導致某些用戶無法忍受超長的響應時間而放棄。
對應到我們上面理髮店的例子,每小時3個顧客就是這個理髮店的最佳並發用戶數,而每小時9個顧客則是它的最大並發用戶數。當每小時都有3個顧客到來時,理髮店的整體工作效率最高;而當每小時都有9個顧客到來時,前幾個小時來的顧客還可以忍受,但是隨著等待的顧客人數越來越多,等待時間越來越長,最終還是會有顧客無法忍受而離開。同時,隨著理髮店裡顧客人數的增多和理髮師工作時間的延長,理髮師會逐漸產生疲勞,還要多花一些時間來清理環境和維持秩序,這些因素將最終導致理髮師的工作效率隨著顧客人數的增多和工作的延長而逐漸的下降,到最後可能要1.5小時甚至2個小時才能剪完1個發了。
當然,如果一開始就有10個顧客到來,則註定有1位顧客剪不到頭髮了。
進一步理解「最佳並發用戶數」和「最大並發用戶數」
在上一節中,我們詳細的描述了並發用戶數同資源佔用情況、吞吐量以及響應時間的關係,並且提到了兩個新的概念——「最佳並發用戶數(The Optimum Number of Concurrent Users)」和「最大並發用戶數(The Maximum Number of Concurrent Users)」。在這一節中,我們將對「最佳並發用戶數」和「最大並發用戶數」的定義做更加清晰和明確的說明。
對於一個確定的被測系統來說,在某個具體的軟硬體環境下,它的「最佳並發用戶數」和「最大並發用戶數」都是客觀存在。以「最佳並發用戶數」為例,假如一個系統的最佳並發用戶數是50,那麼一旦並發量超過這個值,系統的吞吐量和響應時間必然會「此消彼長」;如果系統負載長期大於這個數,必然會導致用戶的滿意度降低並最終達到一種無法忍受的地步。所以我們應該保證最佳並發用戶數要大於系統的平均負載。
要補充的一點是,當我們需要對一個系統長時間施加壓力——例如連續加壓3-5天,來驗證系統的可靠性或者說穩定性時,我們所使用的並發用戶數應該等於或小於「最佳並發用戶數」——大家也可以結合上面的討論想想這是為什麼 ^_^
而對於最大並發用戶數的識別,需要考慮和鑒別一下以下兩種情況:
1.當系統的負載達到最大並發用戶數後,響應時間超過了用戶可以忍受的最大限度——這個限度應該來源於性能需求,例如:在某個級別的負載下,系統的響應時間應該小於5秒。這裡容易疏忽的一點是,不要把顧客因為無法忍受而離開時店內的顧客數量作為理髮店的「最大並發用戶數」,因為這位顧客是在3小時前到達的,也就是說3小時前理髮店內的顧客數量才是我們要找的「最大並發用戶數」。而且,這位顧客的離開只是一個開始,可能有會更多的顧客隨後也因為無法忍受超長的等待時間而離開;
2.在響應時間還沒有到達用戶可忍受的最大限度前,有可能已經出現了用戶請求的失敗。以理髮店模型為例,如果理髮店只能容納6位顧客,那麼當7位顧客同時來到理髮店時,雖然我們可以知道所有顧客都能在可容忍的時間內剪完頭髮,但是因為理髮店容量有限,最終只好有一位顧客打道回府,改天再來。
對於一個系統來說,我們應該確保系統的最大並發用戶數要大於系統需要承受的峰值負載。
如果你已經理解了上面提到的全部的概念,我想你可以展開進一步的思考,回頭看一下自己以往做過的性能測試,看看是否可以對以往的工作產生新的理解。也歡迎大家在這裡提出自己的心得或疑惑,繼續討論下去。
理髮店模型的進一步擴展
這一節中我會提到一些對理髮店模型的擴展,當然,我依然是只講述現實中的理髮店的故事,至於如何將這些擴展同性能測試以及性能解決方案等方面關聯起來,就留給大家繼續思考了 ^_^
擴展場景1:有些顧客已經是理髮店的老顧客,他們和理髮師已經非常熟悉,理髮師可以不用花費太多時間溝通就知道這位顧客的想法。並且理髮師對這位顧客的腦袋的形狀也很熟悉,所以可以更快的完成一次理髮的工作。
擴展場景2:理髮店並不是只有剪髮一種業務,還提供了燙髮染髮之類的業務,那麼當顧客提出新的要求時,理髮師服務一位顧客的時間可能會超過標準的1小時。而且這時如果要計算每位顧客的等待時間就變得複雜了很多,有些顧客的排隊時間會比原來預計的延長,並最終導致他們因為無法忍受而離開。
擴展場景3:隨著燙髮和染髮業務的增加,理髮師們決定分工,兩位專門剪髮,一位專門負責燙髮和染髮。
擴展場景4:理髮店的生意越來越好,理髮師的數量和理髮店的門面已經無法滿足顧客的要求,於是理髮店的老闆決定在旁邊再開一家店,並招聘一些工作能力更強的理髮師。
擴展場景5:理髮店的生意變得極為火爆了,兩家店都無法滿足顧客數量增長的需求,並且有些顧客開始反映到理髮店的路途太遠,到了以後又因為燙髮和染髮的人太多而等太久。可是理髮店的老闆也明白燙髮和染髮的收入要遠遠高於剪髮阿,於是他腦筋一轉,決定繼續改變策略,在附近的幾個大型小區租用小的鋪面開設分店,專職剪髮業務;再在市區的繁華路段開設旗艦店,專門為燙髮、染髮的顧客,以及VIP顧客服務。並增設800電話,當顧客想要剪髮時,可以撥打這個電話,並由服務人員根據顧客的居住地點,將其指引到距離最近的一家分店去。
這篇文章就先寫到這裡了,希望大家在看完之後可以繼續思考一下,也寫出自己的心得體會或者新的想法,記下自己的不解和疑惑,讓我們在不斷的交流和討論中走的更遠 ^_^
作者的比喻非常生動,轉載希望對大家有幫助~
推薦閱讀:
※前端性能測試,TTFB太長怎麼辦-魯德
※JMeter之旅01
※80後測試工程師的中年危機,不知道自己還能不能幹測試,能幹多久