LoadRunner 沒有告訴你的之三:理髮店模型

引言

大概在一年前的一次討論中,個人好友陳華第一次提到了這個模型的最第一版本,通過幾回討論後,咱們發現通過完善和擴展的「理髮店模型」能夠用來幫助咱們理解不少性能測試的概念和理論,以及一些測試中遇到的問題。在最近的一次討論後,我決定撰寫一篇文章來專門講述一下這個模型,但願能夠幫助你們更好的理解性能測試有關的知識。php

    不過,在這篇文章中,我將會盡可能的只描述模型自己以及相關的一些擴展,而具體如何將這個模型徹底同性能測試關聯起來,我不會所有說破,留下足夠的空間讓你們繼續思考和總結,最好也一塊兒來對這個模型作進一步的完善和擴展^_^ 我相信,當你們在思考的過程當中有所收穫並有所突破時,那種快感和收穫的喜悅才真的是讓人倍感振奮並且終生難忘的 ^_^併發

    固然,我要說明的是,這個模型僅僅是1個模型,它與你們實際工做中遇到的各式各樣的狀況未必均可以一一對應,可是大的方向和趨勢應該是一致的。 性能

    相信你們都進過或見過理髮店,一間或大或小的鋪面,1個或幾個理髮師,幾張理髮用的椅子和供顧客等待的長條板凳。測試

條件假設

在咱們的這個理髮店中,咱們事先作了以下的假設:spa

1. 理髮店共有3名理髮師;blog

2. 每位理髮師剪一個發的時間都是1小時;事務

3. 咱們顧客們都是頗有時間觀念的人並且很是挑剔,他們對於每次光顧理髮店時所能容忍的等待時間+剪髮時間是3小時,並且等待時間越長,顧客的滿意度越低。若是3個小時還不能剪完頭髮,咱們的顧客會立馬生氣的走人。資源

場景想象

  經過上面的假設咱們不難想象出下面的場景:get

  1. 當理髮店內只有1位顧客時,只須要有1名理髮師爲他提供服務,其餘兩名理髮師可能繼續等着,也可能會幫忙打打雜。1小時後,這位顧客剪完頭髮出門走了。那麼在這1個小時裏,整個理髮店只服務了1位顧客,這位顧客花費在此次剪髮的時間是1小時;io

  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電話,當顧客想要剪髮時,能夠撥打這個電話,並由服務人員根據顧客的居住地點,將其指引到距離最近的一家分店去。

 這篇文章就先寫到這裏了,但願你們在看完以後能夠繼續思考一下,也寫出本身的心得體會或者新的想法,記下本身的不解和疑惑,讓咱們在不斷的交流和討論中走的更遠 ^_^

相關文章
相關標籤/搜索