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

并發數 = RPS * 響應時間

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

100工人的問題

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

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

問：節點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)

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

為了描述方便，我們将節點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部分：

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

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

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

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

對了，前面的分析漏了一個影響并發性能測試結果的非常重要的因素：思考時間（用戶在操作的時候，步驟之間用戶會停頓一段時間）。思考時間的引入會将并發的建模的複雜度帶到幾乎不能實現的地步，因為它不像其他相對客觀的因素，它是非常主觀的。假如用戶停留的時間很長，可能是因為感興趣多看一會兒，或者頁面上有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 模式壓測在容量規劃的典型應用，是并發模式無法實現的。正式因為此，我們才能将性能測試從“定性分析”轉化為“定量分析”。

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

結尾：無意引戰

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

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

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