《LoadRunner性能測試巧匠訓練營》——1.5 性能測試模型分析

本節書摘來自華章計算機《loadrunner性能測試巧匠訓練營》一書中的第1章，第1.5節,作者：趙　強　鄒偉偉　任健勇 更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

經過上面的學習，小白對基本的性能測試概念等有了深刻了解，為了能把這些概念應用到實際項目中，小白開始對典型的性能測試模型進行學習，逐漸把概念、名額運用起來，并培養自己的觀察分析能力。

1.5.1　曲線拐點模型分析

對于初學者來說，培養觀察與分析思想是很重要的，首先來看一張典型的曲線拐點模型圖，如圖1-2所示。

分析圖1-2最好是先看一個個名額，然後再綜合分析，這樣的步驟更容易了解，思路也更加清晰明了。接下來就和小白一起來分析吧，分析思路如下。

1）x軸代表并發使用者數，y軸代表資源使用率、吞吐量、響應時間。x軸與y軸區域從左往右分别是輕壓力區、重壓力區、拐點區。

2）然後一個個分析，根據前面學習的性能術語與名額進行了解，随着并發使用者數的增加，在輕壓力區的響應時間變化不大，比較平緩，進入重壓力區後呈現增長的趨勢，最後進入拐點區後傾斜率增大，響應時間急劇增加。

3）接着看吞吐量，随着并發使用者數的增加，吞吐量增加，進入重壓力區後逐漸平穩，到達拐點區後急劇下降，說明系統已經達到了處理極限，有點要扛不住的感覺。

4）同理，随着并發使用者數的增加，資源使用率逐漸上升，最後達到飽和狀态。

5）最後，把所有名額融合到一起來分析，随着并發使用者數的增加，吞吐量與資源使用率增加，說明系統在積極處理，是以響應時間增加得并不明顯，處于比較好的狀态。但随着并發使用者數的持續增加，壓力也在持續加大，吞吐量與資源使用率都達到了飽和，随後吞吐量急劇下降，造成響應時間急劇增長。輕壓力區與重壓力區的交界點是系統的最佳并發使用者數，因為各種資源都利用充分，響應也很快；而重壓力區與拐點區的交界點就是系統的最大并發使用者數，因為超過這個點，系統性能将會急劇下降甚至崩潰。

分析到這裡，小白終于找到點成就感了，同時也慶幸自己沒有忽略基礎，看來基礎對于日後的學習有着重要意義！

1.5.2　地鐵模型分析

和絕大部分人一樣，小白每天都要乘坐地鐵上下班，那麼就拿地鐵來分析，再次深刻了解下性能。早上乘坐地鐵上班，最典型的就是北京地鐵1、5、10、13号線等，人多得簡直沒法形容！為了友善了解分析，先做如下假設。

某地鐵站進站隻有3個刷卡機。

人少的情況下，每位乘客很快就可以刷卡進站，假設進站需要1s。

乘客耐心有限，如果等待超過30min，就會暴躁、唠叨，甚至選擇放棄。

按照上述的假設，最初會出現如下的場景。

場景一：隻有1名乘客進站時，這名乘客可以在1s的時間内完成進站，且隻利用了一台刷卡機，剩餘2台等待着。

場景二：隻有2名乘客進站時，2名乘客仍都可以在1s的時間内完成進站，且利用了2台刷卡機，剩餘1台等待着。

場景三：隻有3名乘客進站時，3名乘客還能在1s的時間内完成進站，且利用了3台刷卡機，資源得到充分利用。

想到這裡，小白越來越覺得有意思了，原來技術與生活這麼息息相關，真的可以快樂學習哦。随着上班高峰的到來，乘客也越來越多，新的場景也慢慢出現了。

場景四：a、b、c三名乘客進站，同時d、e、f乘客也要進站，因為a、b、c先到，是以d、e、f乘客需要排隊，等a、b、c三名乘客進站完成後才行。那麼，a、b、c乘客進站時間為1s，而d、e、f乘客必須等待1s，是以他們3位在進站的時間是2s。

通過上面這個場景可以發現，每秒能使3名乘客進站，第1s是a、b、c，第2s是d、e、f，但是對于乘客d、e、f來說，“響應時間”延長了。

場景五：假設這次進站一次來了9名乘客，根據上面的場景，不難推斷出，這9名乘客中有3名的“響應時間”為1s，有3名的“響應時間”為2s（等待1s+進站1s），還有3名的“響應時間”為3s（等待2s+進站1s）。

場景六：假設這次進站一次來了10名乘客，根據上面的推算，必然存在1名乘客的“響應時間”為4s，如果随着大量的人流湧入進站，可想而知就會達到乘客的忍耐極限。

場景七：如果地鐵正好在火車站，例如，著名的北京西站、北京站。每名乘客都拿着大小不同的包，有的乘客拿的包太大導緻卡在刷卡機那（堵塞），這樣每名乘客的進站時間就會又不一樣。

小白突然想到，貌似很多地鐵進站的刷卡機有加寬的和正常寬度的兩種類型，那麼拿大包的乘客可以通過加寬的刷卡機快速進站（增加帶寬），這樣就能避免場景七中的現象。

場景八：進站的乘客越來越多，3台刷卡機已經無法滿足需求，于是為了減少人流的積壓，需要再多開幾個刷卡機，增加進站的人流與速度（提升tps、增大連接配接數）。

場景九：終于到了上班高峰時間了，乘客數量上升太快，現有的進站措施已經無法滿足，越來越多的人開始抱怨、擁擠，情況越來越糟。單單增加刷卡機已經不行了，此時的乘客就相當于“請求”，乘客不是在地鐵進站排隊，就是在站台排隊等車，已經造成嚴重的“堵塞”，那麼增加發車頻率（加快應用、資料庫的處理速度）、增加車廂數量（增加記憶體、增大吞吐量）、增加線路（增加服務的線程）、限流、分流等多種措施便應需而生。

分析到這裡，小白可以熟練地把性能名額與場景結合運用起來了，初步學習成果還是不錯的。