13丨性能測試場景：如何進行場景設計

我們在前面屢次強調了場景的重要性，今天終於到了要把實際場景拿出來解析的時候了。

在本篇文章中，為了保證數據的連續性，我用之前的項目資料來作明確地說明。同時為了模糊關鍵業務信息，以及讓場景的描述更通用性，我會把所有的業務名隱去。

根據之前我們所說的，基准性能場景是為了測試出單業務的最大容量，以便在混合容量場景中判斷哪個業務對整體容量最有影響。

今天的場景設計需要說明兩個前提條件：

1. 這些業務都是實時的業務，不涉及批處理、大數據等業務。
2. 因為本篇着重講場景的設計和具體項目的操作，所以不加系統資源的分析，避免信息混亂。

在這個場景設計中，首先，我們要列出自己要測試的業務比例、業務目標TPS和響應時間指標。

在這個項目中，響應時間指標是統一的，就是不大於100ms。

其實我們在做項目的時候，經常會這樣制定一個統一的響應時間指標，這樣做也不是完全因為懶，更多的是根本不知道如何定每個業務的時間。但我們性能測試人員要知道，這顯然是不對的，因為業務不同，響應時間指標也應該不同，合理的做法是給出每個業務的響應時間指標。下面我們還會遇到響應時間定得不夠細致的問題。

有了這個列表，下一步就是做基准性能測試了。

基准性能場景

有很多人做接口測試的時候，覺得接口的TPS真是高呀，於是就按照最高的TPS跟老板匯報。但我們一定要知道的是，接口的TPS再高，都無法說明容量場景的情況，除非這個服務只有這一個接口，並且也只為了測試服務，這時就不必有混合的情況了。

首先，我們要知道，每個業務在系統中的最大容量是多少。那么接下來，我們用上面的業務一個一個地做基准，看看結果如何。

業務1

場景執行時長：17分鍾。

先看Statistics。

很多人喜歡用這個表中的數據來做報告，特別是90th pct、95th pct、99th pct。我不是說不能用，但是，我們要先知道這個場景是什么樣，再來確定這些值是不是可以用。

從上圖來看，TPS達到573.24，平均響應時間是109.83ms，發送字節很少，這里都沒統計到，接收字節966.22KB/sec，這個值也非常低，最小響應時間43ms，最大響應時間694ms。

但是！這能說明什么呢？什么都說明不了呀。是好是壞？不知道呀。所以我們還需要看其他圖。

我們先看一下線程圖。

以每分鍾15個用戶的速度往上遞增。

對應的響應時間圖是下面這樣的。

隨着用戶的增加，響應時間一直都在增加，顯然瓶頸已經出現了。

我們再結合Statistics表格中幾個和時間有關的值來想想一想，90th pct、95th pct、99th pct、平均響應時間還可以用嗎？ Statistics的平均響應時間是109.83ms，但是你從響應時間圖和線程圖比對就可以看到，在不同的線程階梯，響應時間是有很大差別的。所以Statistics中的響應時間都是針對整個場景來說的，然而在梯度加壓的過程中，用Statistics中的數據是不合理的。

接着我們再來看下TPS圖：

我們可以從TPS圖上看到，最大TPS能達到680左右。我再啰嗦一句，請你不要再用所謂的”最大TPS拐點“這樣的描述來說明TPS曲線，我在第6篇文章中也說過，性能的衰減是逐步的（也有突然的情況，那是非常明顯的性能瓶頸了），在最大TPS出現之前，就已經可以判斷瓶頸是否出現了。

結合上面四個圖，我們就有了如下的判斷：

1. 場景是遞增的。
2. 壓力線程上升到55（第四個階梯）時，TPS達到上限680左右，但是明顯的，性能在第三個階梯就已經接近上限了，
3. 在壓力線程達到55時，響應時間達到85ms左右，這個值並不高。

除此之外，其他的似乎不需要我們再做什么判斷了。

也許這時候你會想問，那么瓶頸在哪里呢？總有人看到現象就想知道結果。但是這一次呢，我不打算滿足這樣的好奇心，因為本篇只是為了講場景的邏輯，而不是瓶頸的分析。哈哈。

業務2

從業務2開始，我們不做啰嗦的數據解釋了，只說明一下關鍵點。我們看圖。

Statistics圖：

線程數：

響應時間圖：

TPS圖：

基於上面的四張圖，我們可以看到：

1. 這個單業務的最大TPS在6000以上。
2. 響應時間變化比較小，基本上都在10ms以下，但也能明顯看出在線程增加的過程中，響應時間也是在增加的。

這個業務由於TPS太高，響應時間太短，實在沒啥可分析的。

業務3

接下來再看一下業務3的情況。

Statistics：

線程數：

響應時間圖：

TPS圖：

基於上面四張圖，我們可以看到：

1. 最大TPS將近5000。
2. 響應時間隨着用戶的增加而增加，在達到4500TPS時，響應時間在6.5ms左右。

業務4

Statistics：

線程數：

響應時間圖：

TPS圖：

基於上面四張圖，我們可以看到：

1. 最大TPS超過了300。
2. 響應時間隨着用戶的增而增加，在達到300TPS時，響應時間在70ms左右。

業務5

Statistics：

線程數：

響應時間圖：

TPS圖：

基於上面四張圖，我們可以看到：

1. 最大TPS在550左右。
2. 響應時間隨着用戶的增而增加，在達到550TPS時，響應時間在55ms左右。

業務6

Statistics：

線程數：

響應時間圖：

TPS圖：

基於上面四張圖，我們可以看到：

1. 最大TPS超過了2500。
2. 響應時間隨着用戶的增而增加，在達到4500TPS時，響應時間在16ms左右。

有了上面這些單業務的容量結果，我們就可以做一個表格了：

還記得我們前面提到響應時間都不能大於100ms吧。通過測試結果我們可以看到，業務1已經接近這個指標了，也就是說這個業務如果在活動或促銷期，有可能出現峰值最大TPS超過承受值的情況，超過了前面制定的響應時間指標。

有了這些基礎數據之后，下面我們就可以設計容量場景了。

容量性能場景

我們希望得到的容量場景在本文的一開始就已經給出。下面我們通過設計線程來得到這個容量場景的結果。

你需要記住我們的重點：

1. 場景不斷。
2. 控制比例。

我們這里只說一個容量性能場景，並且這個場景是峰值業務場景。如果在你的項目中，有特定的業務日，那就要根據業務日的業務比例，重新做一個針對性的場景。

在滿足了最開始提到的業務比例之后，我們不斷增加壓力，得到如下結果。

Statistics：

線程數：

響應時間圖：

總TPS圖：

TPS細分圖：

從上面的結果可以看到，業務4和業務5的響應時間，隨着業務的增加而增加，這顯然在容量上會影響整體的性能。

在具體的項目中，這就是我們要分析調優的后續方向。

還有一點請你注意，並不是說，看到了性能瓶頸就一定要解決，事實上，只要業務指標可控，不調優仍然可以上線。這一點也是很多做性能測試的人會糾結的地方，感覺看到這種有衰減趨勢的，就一定要把它給調平了。其實這是沒有必要的。我們做性能是為了讓系統能支持業務，即使性能衰減已經出現，性能瓶頸也在了，只要線上業務沒有超出容量場景的范圍，那就仍然可以上線。

另外再說幾句閑話，做技術的人容易鑽進這樣的牛角尖，覺得明顯有問題，結果公司老板不支持去調優處理，顯然是老板不重視性能測試，於是深感自己不得志，工作也無精打采的。這就沒必要了，做性能不是為了炫技，應該為業務服務。

我們再說回來，從總TPS圖上看到，在容量測試中，我們仍然測試到了系統的上限。這是一個好事情，讓我們可以判斷出線上的系統配置應該是什么樣的。

在達到了系統上限時，我們來看一個業務的比例（請你注意，我是不贊同用表格來承載分析數據的，但是作為最終的結果，給老板看的時候，還是要盡量說得通俗易懂）。

如下所示：

我們可以從上面的數據中看到，業務目標TPS已經達到，響應時間也沒有超過指標。很好，這個容量就完全滿足業務需求了。

但是！

如果業務要擴展的話，有兩個業務將會先受到影響，那就是業務4和業務5，因為它們的測試TPS和最大TPS最為接近。這是在我們推算業務擴展之后，再做架構分析時要重點考慮的內容。如果是在實際的項目中，這里會標記一個業務擴展風險。

請你注意，根據架構，性能測試組需要根據當前的測試狀態整理架構的關鍵配置給線上系統做為參考，並且每個項目都會不一樣，所以並不是固定的內容。我想做運維的看到這些值可能會更為親切。

在這里，我給一個之前項目中的示例（由於屬於項目交付類文檔，所以這里只截取部分技術片斷），如下所示：

配置整理的范圍包括架構中所有和性能相關的技術參數。如下所示：

當然，這時我們也是要分析系統的資源使用率的。在本文為了避免混亂，所以我沒有提及。在實際的項目中，我們還是要分析的哦。

說完了混合容量場景之后，我們回憶一下之前說過的兩個重點，我的混合業務場景是不是沒有斷？是不是保持了業務比例？

下面我們就該說一下穩定性場景了。

穩定性性能場景

我在第1篇文章就提到過，穩定性場景的時間長度取決於系統上線后的運維周期。

在這個示例中，業務+運維部門聯合給出了一個指標，那就是系統要穩定運行一周，支持2000萬業務量。運維團隊每周做全面系統的健康檢查。當然誰沒事也不用去重啟系統，只要檢查系統是否還在健康運行即可。大部分時候運維是等着系統警告的。

那么針對前面給出的容量結果，容量TPS能達到3800（業務1到業務6的容量測試結果TPS總和）。所以穩定性場景時間應該是：20000000/3800 = 1.46小時。

下面是兩小時的穩定性場景運行情況，我在這里只做一下大概的說明。

Statistics：

線程數：

響應時間圖：

TPS細分圖：

總TPS圖：

從上面幾張圖可以看出，業務2和業務3對總TPS的動盪產生了影響，但系統並沒有報錯。這種周期性的影響，你可以去分析具體的原因，由於本篇是場景篇，所以這里不寫分析過程，直接給出原因，這種影響是參數化數據周期性使用所導致的，有些數據的關聯記錄數多，有些數據的關聯記錄數少，數據庫中變化倒是不大，但由於TPS過高，表現出來得就比較明顯了。

其他的業務都比較正常，也比較穩定，沒有報錯。

總體業務量達到27299712，也達到了穩定性業務量級的要求。

有一點，估計會有人提出疑問，你這個穩定性的總體TPS，看起來和容量測試場景中差不多呀，有必要用容量測試中的最大TPS來跑穩定性嗎？

這里就涉及到另一個被誤解的穩定性知識點了。有很多人在資料中看到，穩定性測試應該用最大TPS的80%來跑。看到沒有，這似乎又是一個由28原則導致的慣性思維。

在這里我要澄清一下。在具體的項目實施過程中，完全沒有必要遵守這些看似有道理，實則對具體項目沒什么用的原則。

這個系統用最大TPS能跑下來，業務一直很正常，穩定性目標能達到，為什么不能用最大TPS來跑呢？本來穩定性場景就是為了知道會不會由於長時間處理業務而引發潛在瓶頸（像內存泄露是個典型問題）。至於用多大的TPS來運行，又有什么關系？只要系統在正常處理，資源沒有出現問題，也沒有報錯，那這個場景就是有效的，目標也是能達到的。

所以說，這里的穩定性場景，完全合理。但是，你覺得這樣就完了嗎？當然沒有，我們還有異常場景要做嘛。

異常性能場景

我之前有提到過，異常性能場景要看架構圖，但是涉及到職業素養的問題，我這里只能畫個示意圖來說明此系統的架構，以此來實現邏輯的完整性。示意圖如下所示：

這是一個完全按生產架構來的示意圖，在真實的測試過程中，也是這樣搭建的。在這里有六個業務區域（包含基礎架構區），也有DMZ區。

其實在每個區域中，根據架構中用到的技術組件，異常測試都有細化的場景設計，而在這里，我給你展示一個全局架構層的場景，用來說明異常場景。

這里運行的場景是：用容量場景中最大TPS的50%來做異常的壓力背景。

咦，是不是會有人問：這里為什么只用50%了？穩定性性能場景不是還用100%的壓力背景嘛？

這里我就要再說一遍，看目標！異常性能場景的目標是為了判斷所要執行的操作對系統產生的影響，如果TPS不穩定，怎么能看出來異常點？當然是穩定無抖動的TPS是最容易做出異常動作產生的影響了。所以這里的50%是為了得到更為平穩的TPS曲線，以便做出正確的判斷。

下面我們就要看異常場景的設計了。這是一個大的異常場景。

我分別對各區域中的業務應用服務器、數據庫服務器以及基礎架構服務器做異常操作（為了方便理解，下文我直接用kill來說明，其實在操作中，有些不是直接kill，像斷電、斷網卡的手段也都可以用，取決於如何操作更為准確）。

下面是具體的操作步驟和時間記錄。

第一部分：業務應用服務器。停下如下區域的一半應用服務器，查看TPS、響應時間及其他服務器壓力。

1. kill 區域三：17:02；
2. kill 區域一：17:15；
3. kill 區域二：17:20；
4. kill 區域五：17:25。

第二部分：基礎架構服務器。停下一半的基礎架構主機，查看TPS、響應時間及另外主機壓力的恢復情況。

kill 一台基礎架構主機中的某個服務的某個節點：17:30。

第三部分：數據庫服務器。停下master數據庫，查看切換時間，slave的壓力及TPS的恢復情況。

1. reboot DB-20：17:36。6分鍾之后恢復；
2. reboot DB-26：18:07。1分鍾左右恢復；
3. reboot DB-2：18:20。2分鍾之后恢復。

第四部分：啟動master數據庫。

第五部分：啟動被停的應用服務。

1. start 區域五：18:28；
2. start 區域三：18:33；
3. start 區域一：18:38；
4. start 區域二：18:43。

第六部分：啟動被停基礎架構主機中的某個服務的某個節點。

start 基礎架構主機中的某個服務的某個節點：18:48。

根據上面的步驟，這里我放出TPS圖來做分析。

從上圖中的TPS趨勢可以看出，停掉一半的區域三應用服務器后，對TPS有明顯的影響。為啥呢？

我們來看一下細分的TPS圖：

從圖上看，並不是所有的TPS都在步驟1的時候受到了影響。受影響的只有業務2和業務3。顯然只有業務2和業務3走到了這個區域。但是這仍然是一個BUG！！！

理論上，用一半的壓力，停了一半的服務器，即便當前正在運行在被停掉的服務器上的session受到了影響，那TPS也應該會恢復的，但是TPS沒恢復。所以先這里提個BUG。

另外，停掉區域一、二、五的一半應用服務器，影響不大，TPS有些許下降，但並沒有報錯，這個結果還可以接受。

停掉基礎架構服務器時，TPS有下降，但很快恢復了，非常好。

在步驟6時，記錄的信息是在6分鍾之后恢復的，這個時間有點久了。我在這里拆開TPS細節來看一下。

顯然這段報錯得比較多，6分鍾，一個master庫切換過去。這怎么能接受呢？報BUG！！！

另外，步驟8中，TPS顯然下降到底了。還好時間並不長，在2分鍾后恢復。這個可以報BUG。為什么說是可以報呢？因為這個時間並不算長。這里就有一個預期的問題。通常情況下，我們做DB master的異常切換，在這個架構中，是期望在1分鍾內完成切換的。在我這個場景中，最快的數據庫master切換是40s。

請你注意，我看到有些廠商說數據庫可以達到秒級切換，這種說法未免過於空泛。如果把”不到1分鍾“稱為秒級的話，那就欲蓋彌彰了。我理解的秒級切換是一秒內，而不是單位是秒就可以。

通常這種1秒內切換說的都只是數據庫實例的前面一層，有叫Plus的，有叫Proxy的，並且說的不是從出現異常，到判斷切換的過程。而是說從切換動作開始到結束。另外，這個秒級切換也是有背景條件的。我們不要看廣告，要看實際的操作結果。

請注意，上面提到的容量場景和異常場景，都只是項目中的一個場景。其實在這個項目中，我還有很多其它的容量場景和異常場景。從場景設計上來說，這些場景都大同小異，但都需要在大量的調研分析之后才能設計得出來。