5g吞吐性能測試?本文是《如何做好性能壓測》系列專題分享的第四期，該專題将從性能壓測的設計、實現、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解，以幫助大家構建完整的性能壓測的理論體系，并提供有例可依的實戰，下面我們就來聊聊關于5g吞吐性能測試?接下來我們就一起去了解一下吧!

5g吞吐性能測試

本文是《如何做好性能壓測》系列專題分享的第四期，該專題将從性能壓測的設計、實現、執行、監控、問題定位和分析、應用場景等多個緯度對性能壓測的全過程進行拆解，以幫助大家構建完整的性能壓測的理論體系，并提供有例可依的實戰。

該系列專題分享由阿裡巴巴 PTS 團隊出品，歡迎在文末處加入性能壓測交流群，參與該系列的線上分享。

第一期：《壓測環境的設計和搭建》

第二期：《性能壓測工具選型對比》

第三期：《阿裡巴巴在開源壓測工具 Jmeter 上的實踐和優化》

1996年， LR 4.0 版本發布，将性能測試專業理論工具化、産品化，這直接影響之後20多年性能測試領域的理論基礎。但是 LR 作為一款商業化産品，因其價格昂貴，推廣和傳播受限。1998年底，JMeter 開源 ，并發布1.0版本，性能測試領域逐漸蓬勃發展起來。

Loadrunner、Jmeter 引領了性能測試領域的一個時代，功能強大，腳本化，擴展性強，将性能測試标準化、專業化，後續幾乎所有性能測試工具或者商業化産品都馬首是瞻。本文就性能測試做了一個純YY的“實踐”（真的隻是純理論分析！），有一些不一樣的思路跟大家一起探讨下，望輕踩。

前言：并發、RPS 和 RT

接觸性能測試的同學要理解的概念有非常多，在正文之前先跟大家就幾個核心指标統一下口徑：

并發用戶、并發、VU：一般用來表示虛拟用戶（Virutal User，簡稱VU），對應到 Jmeter 的線程組線程，對應到 Loadrunner 的并發 Concurrency ，在本文都是一個意思。

每秒發送請求數、RPS：指客戶端每秒發出的請求數，有些地方也叫做QPS，本文不單獨讨論“事務”所以可以近似對應到Loadrunner的TPS（Transaction Per Second, 每秒事務數），本文統一叫做 RPS。

響應時間、RT：對，沒錯，這個就是你理解的那個意思，從發起請求到完全接收到應答的時間消耗。

根據“Little定律”，在平衡狀态下，我們可以等價認為并發、RPS 和 RT 之間的關系可以概括為：并發數 = RPS * 響應時間

偷懶的話，可以把它當成性能測試領域的“乘法口訣”，直接背下來吧，他會幫助你快速理解很多問題；如果想深入了解具體的原理可以去拜讀下 Eric Man Wong 在2004年發表了名為《Method for Estimating the Number of Concurrent Users》的文章，這兩者是等價的。

100工人的問題

如果你還不了解“RT對于并發模式的性能測試的影響”或者還存在一些疑惑，強烈建議讀完本節；如果不想理解細節，可以選擇直接跳到本節末尾看結論；如果已經充分了解了，可以直接跳過本節。

先從一個大家相對熟知的例子開始，假設有這麼一條生産箱子的流水線，安排了100個工人，條件如下：

100個工人的身體素質一模一樣， 因此可以近似的認為工作效率隻與工作的複雜度有關；

這個流水線有3份工作（如下圖所示的節點A、節點B和節點C），所有工人都可以勝任；

節點A工人包裝箱子平均耗時 RT1=0.5s（秒），節點B工人包裝箱子平均耗時 RT2=3s（秒），節點C工人包裝箱子平均耗時 RT3=1.5s（秒）;

同一個箱子必須按照 節點A、節點B、節點C 的順序被包裝。

問：節點A、節點B、節點C分别安排多少工人 X、Y、Z 可以讓這個流水線達到最大的産能，并且求得流水線的最大産能 T/s？（如下圖）

在平衡狀态下，我們從宏觀的視角來分析下，整條流水線包裝完一個箱子的 總耗時=(0.5 3 1.5)s，那麼我們可以很輕易地得到流水線的産能：

流水線的産能 T = 100 / (0.5 3 1.5) = 20 /s

可能很多人有疑問，“什麼是平衡狀态？”，這個可以這麼理解，為了保證所有工人都可以達到最大的工作效率，主管會非常睿智的調配各個節點之間的工人分配直到“所有工人都有事可做，也不會存在工人忙不過來”，那麼從微觀的角度去看，如果節點之間的産能不一緻，有些節點就會出現箱子等待被處理，有些節點的工人等待箱子的情況。所以，我們可以得到這樣的結論 在平衡狀态下，所有節點産能肯定是一緻的：

T(A) = T(B) = T(C) = T = 20 /s

從而，根據Little定律，我們可以推算出來，各個節點的人員（vu）分配了：

X = T(A) RT1 = 20 0.5 = 10

Y = T(B) RT2 = 20 3 = 60

Z = T(C) RT3 = 20 1.5 = 30

下面這張 Jmeter 的圖，相信大家可以輕易地跟前面的自理找到對照關系，我這裡不再贅述了：

産能 = RPS

工人 = 并發

完成平均時間RT = 響應時間、RT(rt)

綜上所述，我們可以得出兩個結論：

在平衡狀态下，所有節點的 RPS 必然一樣。

在平衡狀态下，任意節點的 RT 都會影響整體 RPS ，進而會影響并發在節點之間的分配關系。

為了描述方便，我們将節點A、節點B和節點C組成的“100人的流水線”叫做“串聯鍊路”。

節點A的RPS = 節點B的RPS = ... = 串聯鍊路RPS

串聯鍊路RPS = 并發數 / (RT1 RT2 ... )

節點N的并發數 = RTn 節點N的RPS = RTn 串聯鍊路RPS

你确定考慮全面了嗎？

控制并發是目前最為普遍被使用到的壓測模式，打個比方，有一個網站大概會在 下周一10:00 預估有 10w人同時訪問，那麼為了保障網站的問題，很自然的想到使用10w個并發來壓測下整個網站的接口，對應到 JMeter 即為設置線程組的線程數，對應到 LoadRunner 設置 VU（Visual User）數，很容易理解。

另外，我從阿裡雲PTS官方拿到近6個月的數據顯示，選擇并發模式與RPS模式分别占比 89%與11%，并發模式占據絕對的規模優勢。

但是，如果你已經充分了解了“RT對于固定并發模式的性能測試的影響”，這裡我不禁要問一句（邪惡臉）“Emm... 你有想過類似Jmeter、LR等并發模式壓測工具拿到的結果是真實的嗎？準确嗎？”。

下面我要講一個“恐怖故事”，先來看一張相對抽象的環境結構圖，

在平衡狀态下，已知總并發VU，以及 接口1、接口2、接口3 的響應時間分别為RT1、RT2、RT3，通過前面的理論基礎，我們可以輕易地寫出下面的算式：

T = RPS1 = RPS2 = RPS3 = VU / (RT1 RT2 RT3)

接口1的并發 X = T * RT1

接口2的并發 Y = T * RT2

接口3的并發 Z = T * RT3

分析下接口的RT的構成，大緻概括為下面5部分：

壓測工具耗時：這個很好理解，壓測工具在發送請求之前會做參數的拼裝/替換、下載應答報文、解析應答報文（斷言）等都是需要耗費時間的，一般情況下壓測工具的時間消耗會非常低，可以忽略。但是對于報文較大或者斷言較複雜的情況下，壓測工具耗時過大也會出現瓶頸；

網絡時間：一般來說在 VPC/IDC 内部的網絡消耗非常低，所以我們可以近似地認為網絡時間消耗都來源于運營商網絡。同樣，對于接口的請求和應答報文比較大的情況下，不論是運營商網絡還是内網網絡的帶寬都更容易出現瓶頸；

安全、鑒權、負載均衡模塊耗時：這一塊的時間消耗一般來說相對較低，受限于連接數、帶寬等，可能會出現由于配置問題，比如連接數上限超過預期，則會造成等待建連超時；

應用業務處理耗時：一般情況下，應用業務處理耗時占據 RT 的百分比最高，也是一般我們可以通過優化提高吞吐量的重點區域。可能包含 應用之間 RPC 服務調用、數據庫SQL執行、讀寫緩存、讀寫消息等。

第三方依賴耗時：這裡就複雜了，各種情況都有，你可以完全信賴或者完全不信賴它的穩定性。一般它的RT評估有相關 SLA 的要求，一般壓測實施的時候根據 SLA 約定的 RT 要求，mock 掉第三方接口依賴，正式壓測的時候再一起聯壓。

更進一步，可以得出這樣的結論，在并發模式下，影響壓測結果以及應用服務器的吞吐量的因素有：

壓測工具的性能

網絡狀态

接入層配置和性能

應用服務性能

第三方依賴的 SLA

...

因此，出現了一種混沌狀态，可能由于壓測工具所在宿主機負載變化、網絡環境變化、應用服務性能優化或者劣化等因素的幹擾，拿着相同的腳本進行了10次，每次得到的接口 RPS 都不一樣，服務器端的壓力也不一樣，但是從表象來看，一切正常，但這樣的性能測試并不能真實反映任何問題，也并不能指導運維做出正确容量規劃的決策。因為影響 RT 的因素實在是太多太多了，任何客觀因素的影響都直接影響測試結果的準确性。

并發模式 = 性能瓶頸“定性”分析

在這裡，我更願意定義并發模式性能測試為一種性能瓶頸分析的定性工具，在盡量相同的條件下經過反複測試，通過分析各個接口的RT構成找到“相對的”性能瓶頸。但是大家有沒有想過，将所有接口優化到極限的性能之後，可以拍胸脯說“我們的系統已經可以抗住 XXX 并發用戶量的訪問了”嗎？答案是否定的，原因有三：

不真實，主要體現在 ① 環境不真實；② 壓測（腳本）模型不真實；

主體錯誤，并發隻是一個誘因和觸發器，影響性能的主體是服務端的RPS；

并發測試的效果真實性依賴于RT，而RT的構成異常複雜。

對了，前面的分析漏了一個影響并發性能測試結果的非常重要的因素：思考時間（用戶在操作的時候，步驟之間用戶會停頓一段時間）。思考時間的引入會将并發的建模的複雜度帶到幾乎不能實現的地步，因為它不像其他相對客觀的因素，它是非常主觀的。假如用戶停留的時間很長，可能是因為感興趣多看一會兒，或者頁面上有100個表單需要填寫，或者看不懂文案是啥意思正在 Google，或者...去沖咖啡了。

有人可能會追問“思考時間究竟要設置多少合适呢？”，我可以非常明确的說“不知道！”，如果你有時間，可以通過大數據 BI 分析統計學意義上的每個接口之間用戶停頓的時間，然後将它設置上，假設每個接口的思考時間總和為 S=(S1 S2 S3)，那麼我們可以更新下公式：

T = RPS1 = RPS2 = RPS3 = VU / (RT1 RT2 RT3 S)

接口1的并發 X = T * RT1

接口2的并發 Y = T * RT2

接口3的并發 Z = T * RT3

可以看到，增加了思考時間之後，整體的吞吐量、所有接口的并發都下降了，因為有部分用戶在“思考”。增加“思考時間”有助于提高并發模式下性能測試的準确性，除此之外，還有一些提高并發模式的準确性的手段：

壓測工具地域定制、運營商定制

增加條件跳轉，模拟用戶重試行為

增加集合點

...

這些手段你可以非常輕易的在市面上的開源或者雲測平台上找到（有些功能可能需要支付一些費用），在這裡不再一一贅述，歸根到底，可以總結為“優化接口 RT 使其接近真實值以提高并發模式的準确性”。

但并發模式始終都受制于“不穩定的”、“難模拟的”、“難預測的”接口 RT ，通過并發模式拿到指導運維進行容量規劃的結果，是要付出的代價會非常大的，甚至也不能達到想要的結果。

在真實情況下，接口1、接口2、接口3的 RPS 是不一樣的，抛開接口異常斷言失敗不繼續調用後面的接口的情況，接口 RPS 關系是呈倒金字塔分布，比方說，浏覽商品（接口）了之後不一定會去下單購買（接口），因為大家一般會反複浏覽不同的商品選擇最中意的再下單，所以浏覽商品（接口）的 RPS 必然會比下單購買（接口）的 RPS 要高，用戶有放棄繼續“走下一步”的權利，但是這種情況你如果嘗試對并發的分布來建模，是一個非常龐大且複雜工程問題，因為影響的因素實在太多了。

如下圖所示，并發壓測模式下，所有接口的 RPS 都是一樣的，與“實際情況”（圖右部分）大相徑庭。

受傳統性能測試思路的影響，目前有接近90%的企業用戶（數據來源于 阿裡雲PTS ） 将并發模式性能測試的結果作為穩定性、容量驗收的依據，所以說這是一件非常恐怖的事情。

容量規劃：從定性分析到定量分析

在這裡我非常樂意跟大家分享一份來源于 QA Intelligence《State of Testing™ Report 2019》關于2016~2019年軟件開發模式的調查數據：

軟件開發模式占比（2019、2018、2017、2016）

數據顯示，DevOps 第一次超過 Waterfall（瀑布模式）成為第二位被越來越多的企業接受的開發模式，而瀑布模式等傳統開發模式有逐漸退出曆史舞台的趨勢。敏捷開發和 DevOps 大行其道，開發、測試和運維等部門、角色之間需要有一種高效的溝通和協作手段。

想到了一句非常“膚淺”但有點道理的話，“性能問題優化之後最終都可以轉化為容量問題”，簡單地可以理解為測試同學發現了性能瓶頸，然後開發同學經過了優化，運維同學根據優化之後的系統的能力進行擴容或者縮容。瞧！這不就是開發、測試和運維完美協作的一個典型實踐嘛？！

這個過程，我們叫做“容量規劃”的實施過程，重點不是容量而是規劃，如果成本不是任何問題，我們可以堆砌無限大的資源，用戶體驗會極其好，但是會造成極大的資源浪費。所以這裡說的“容量規劃”是在保證用戶體驗不受影響（穩定性）的前提下，使有限的資源的利用率最大化（成本）的方法論。打個比方，運維準備了100台機器，有5個應用，那麼“怎麼分配這100台機器給5個應用可以使系統既可以正常對外服務又可以使系統達到最大的吞吐量能力”就是容量規劃要解決的問題。

容量規劃的核心有一張已經用的“泛黃”的圖，大家應該一看就明白，有兩個核心指标：

預估的業務量級：對于單應用而言就是這個應用的RPS吞吐量峰值，這個數據一般可以來源于流量模型和曆史數據沉澱；

單台機器的能力值：在某一個流量模型下，單台機器系統水位達到安全水位時的RPS峰值。

上面提到一個概念叫做“流量模型”，這個流量模型你可以近似的認為就是前面圖中“實際情況”的 RPS 倒金字塔，他有兩個要素：

接口範圍

每個接口的RPS

容量規劃的目的性非常強，也就是在特定“流量模型”下，給出資源分配的最優解。在壓測實施的時候，壓測的主體是接口的 RPS，按照流量模型進行試壓。（如果你還在想為什麼主體是 RPS 而不是并發的話，請在仔細閱讀前面那章）

RPS 模式壓測在容量規劃的典型應用，是并發模式無法實現的。正式因為此，我們才能将性能測試從“定性分析”轉化為“定量分析”。

阿裡在2013年構建了一整套基于線上全鍊路壓測的容量規劃體系，逐漸替代之前單應用、單接口這種低效的容量評估手段，過程也是非常曲折的。容量規劃是一個非常大的課題，本文的重點不是“容量規劃”，如果你對“智能化全鍊路容量規劃”感興趣，請在文末留言或加入我們的性能壓測交流釘群。

結尾：無意引戰

并發模式與 RPS 模式壓測各有各自的使用場景，并發模式更加适用于對于系統定性的分析，比如幫助定位性能瓶頸，單接口的性能基線沉澱（對比曆史性能優化or劣化）；而 RPS 模式在對系統做定量的分析有傑出表現，比如容量規劃、全鍊路性能基線沉澱，當然也可以幫助定位性能瓶頸。并發模式的難點在于 RT 的準确性拟真， RPS 模式的難點在于模型的準确性評估和預測，從實現難度上來說，前者相對于後者來說難度更大一些、掌控度更低一些。

當然，我無意引戰，并發模式、RPS 模式、你想要的和你還沒有想到未來想要的都可以在 阿裡雲PTS 上找到。

本文作者：韓寅，花名隐寒，阿裡雲PTS 高級技術專家，2014年加入阿裡巴巴，一直從事性能測試和高可用領域的相關工作。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!