【騰訊優測乾貨分享】從壓測工具談併發、壓力、吞吐量

本文來自於騰訊bugly開發者社區，非經做者贊成，請勿轉載，原文地址：http://dev.qq.com/topic/580d914e07b7fc1c26a0cf7c

前言

隨着部門業務的拓展，咱們有了不少性能測試的機會，但在實戰中，慢慢發現，咱們對性能測試的理解並不如本身想的那麼清晰，對基本概念和理論的混淆，致使對測試結果的不夠自信，測試過程也常會面臨質疑。

因此這一次，咱們不說性能測試怎麼作，先一塊兒梳理下性能測試的基本理論，分析這些理論如何在壓測工具中產生影響。

系統性能描述

描述一個系統的性能歷來不是一句話或是一個數值的事。

在IEEE的定義中：性能是系統或組件在給定約束中實現的指定功能的程度，諸如速度、正確性、內存使用等。

因此性能測試報告中，對系統性能的描述應該是多方面的，如：執行效率、穩定性、兼容行、可靠性、可擴展性容量等；其中，執行效率經過併發用戶數、響應時間、吞吐量、成功率、資源消耗綜合體現。

併發測試

性能測試有：負載測試、壓力測試、配置測試、併發測試、容量測試、穩定性測試。

其中，併發測試是測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其餘性能問題。

在實際的壓測中，咱們基本上都是設置多個併發，再進行負載測試、壓力測試等，由於現實中，咱們的系統就是面對多個用戶的同時使用，而且，併發用戶的數量，直接影響着系統資源的消耗，例如cpu、mem、網絡鏈接、帶寬，甚至於系統內部邏輯。

併發怎麼看？

所謂併發，它的特色是「並行」和「同時」。

LoadRuner的併發很好理解，就是虛擬用戶數。由於LR有個集合點，能夠在全部虛擬用戶初始化且到達集合點後，再一塊兒執行後續操做，從而達到同時且並行的效果。

但目前在後臺性能測試，咱們本身開發的工具大多不帶集合點功能，這時候使用者對併發的理解就會有點混亂。下面以長鏈接壓測爲例：

最簡單的一種，一個單進程單線程send工具，啓動一次連續發m個包，這種其實屬於單併發，請求串是一個接一個串行到達壓測對象，通常都要再簡單封裝下，相似多進程併發：

for ((i=1; i<=$n; i++))
do
    {
     ./send_${i}    $msg $loop_num
    }
done

注意這樣仍是串行執行，下面這種才能起到併發的做用。

for ((i=1; i<=$n; i++))
do
    {
     ./send_${i}    $msg $loop_num
    }&
done
wait

另外一種是單進程多線程模式，能夠配置起多個線程，一個線程發起一個鏈接到達壓測對象，n個線程就有n個鏈接，

還有一種，鏈接池模式，線程與鏈接數並不一一對應，維持工具到壓測對象的鏈接數不變，線程們從鏈接池挑選空閒的鏈接持續發送請求。

以上三種狀況，假設全部線程極致同步且系統性能足夠，那麼同一時間內（或者說同一瞬間），應該是有等同線程個數的請求同時到達系統，並同時被處理完再一塊兒返回，此時線程就是併發，線程數就是併發數，這裏理解應該沒有問題。

但實際上，全部的併發不可能作到徹底同步，壓測過程當中因爲各類影響，好比：各線程初始化速度不同，鏈接數不夠，處理速度不同等，致使在並行節奏上相互有了誤差， 這種現象在系統接近性能瓶頸時，會更加突出。因此會有同窗疑問，這還能叫「併發」嗎？ 這裏引入「狹義併發」和「廣義併發」的概念。

廣義的併發其實是在一個時間內操做事務的虛擬用戶，而狹義的併發指的是單位時間內向系統發起請求的虛擬用戶，前者是「存在」，後者是「請求」，勿容置疑，壓力不只僅受成功發出請求的用戶帶來的壓力，同時也受「存在」的用戶影響。

這樣看來，工具中的線程數設置，更偏像是廣義併發，表明着在壓測時間段內虛擬用戶總數，這也是併發原始值。而在後續的壓測過程當中，在單位時間內，併發數可能會動態變化，這裏是狹義併發。

當工具產生的壓力遠未到系統性能瓶頸時，理論上，狹義併發=廣義併發=工具線程數；當壓力增長，系統響應時間增加，部分線程的請求處理正常，部分線程可能請求超時，那麼同一單位時間內，同時向系統發起請求的用戶數就不等於線程數了。

那麼咱們如何實時掌握壓測過程當中可能變化的併發？

《Method for Estimating the Number of Concurrent Users》一文介紹了一種併發估算法（網上有不少相關資料，這裏再也不累述）：

C：併發

n：壓測時間段內全部的請求數

L：平均響應時間

T：壓測總時長

這裏注意：L（平均響應時間）≠ T（總時長）/ n（總請求）

壓力是什麼？

壓力就是併發在單位時間內對壓測對象的請求數。在咱們的壓測工具中，有一個配置項專門用來設置壓力，多是全部線程產生的總壓力，也多是單個線程產生的壓力。

有些同窗會在這裏納悶，爲何我設置了發送10w筆/s的請求，系統吞吐量的計算只有1w筆/s，是否是工具備問題？這裏是由於混淆了壓力和性能。

壓力不等於性能，壓力只是檢驗性能的一種手段，對一個性能良好的系統，在必定的壓力下，應該能夠保持正常運轉，若是超過負荷，則應該分流或化解壓力，這也是咱們須要檢驗的

例如：100個併發，1s內發送1w筆請求，若是系統的吞吐量計算大於或等於1w筆/s，說明系統承受住100個併發，1w/s的壓力，咱們能夠增長壓力繼續測試，直到出現性能拐點；若是系統的吞吐量計算是5k筆/s，則說明，若是咱們須要系統應付100個併發，1w/s的壓力，解決方案要麼提高系統性能一倍，要麼擴容一臺分流壓力。

要特別注意：壓力是由工具製造，工具的最大性能決定施加的最大壓力。咱們在測試過程當中曾經遇到壓測系統還沒到極限，工具已經到瓶頸的狀況，這時候獲得的壓測數據是錯誤的。

吞吐量如何計算？

咱們在壓測工具製做中，一直存在一個爭議——吞吐量的計算。

在性能測試中，吞吐量的計算有兩種常見的公式：

公式1： 吞吐量=併發數/平均響應時間

公式2： 吞吐量=請求總數/總時長

公式一、2你們應該都接觸過，雖然看上去不同，其實理論上都是ok的。

首先咱們能夠從C = nL / T 推導：

併發 = 請求總數*平均響應時間 / 總時長

=》併發 / 平均響應時間 = 請求總數 / 總時長

=》公式1 = 公式2

而後咱們構建三組模型進一步論證：

第一組模型

一共有4個線程，同時發了4筆請求，其中3筆耗時1s，一筆耗時2s，整個過程一共耗時2s。

公式1：

平均響應時間 = （1+1+1+2）/ 4= 1.25s ;

併發 = nL/T =4*1.25/2 =2.5

吞吐量 = 2.5 / 1.25 = 2 筆/s

公式2：

吞吐量 = 總筆數/總耗時 = 4/2= 2 筆/s

第二組模型

一共有4個線程，同時發了4筆請求，4筆請求耗時均爲1s，1s內所有發送完畢。

公式1：

平均響應時間 = （1+1+1+1）/ 4= 1s

併發 = nL/T =4*1/1 =4

吞吐量 =  4 / 1= 4 筆/s

公式2：

吞吐量 = 總筆數/總耗時 = 4 / 1= 4 筆/s

第三組模型

一共有4個線程，4筆請求耗時均爲1s，但線程發送出現不一樣步現象，一共持續1.5s完成所有：

公式1：

平均響應時間 = （1+1+1+1）/ 4= 1s

併發 = nL/T =4*1/1 =4

吞吐量 = 4 / 1.5= 2.67 筆/s

公式2：

吞吐量 = 總筆數/總耗時 = 4 / 1.5 = 2.67 筆/s

從咱們構建的模型上看，兩個公式計算的結果是相等的。可是，這種平衡是創建在併發穩定的基礎上，併發若是變化，結果就會有差別。下面咱們看一組真實的壓測數據

從上圖中看出，實際壓測時，兩個公式仍是會有些微差異，這就是由於咱們原本預想併發應該=工具線程數，但在壓測過程當中，實際併發發生了變化，咱們再反推下實際的併發數

計算出的實際併發確實稍低於工具線程數。

結論

1. 在單接口壓測時，咱們用「請求總數/總時長」獲得吞吐量；而後再用「吞吐量/平均響應時間」獲得實際併發，此舉可用來觀察系統實際承受的併發；

2. 在多接口壓測時，因爲短板效應，同一個流程中的全部接口得到的請求總數和總時長都同樣，顯然「請求總數/總時長」計算各個子接口的吞吐量不合適，因此改用「併發/平均響應時間」，其中的併發數應在壓測工具中埋點統計，不可簡單使用工具線程數。

結語

在性能測試平臺的開發中，爲了測試結果更接近現實，咱們在吞吐量計算上改過三個版本，小夥伴們也有過幾回激烈的討論，正是對這種小細節的不斷糾纏，咱們對性能測試的認識也在不斷刷新，本來覺得正確的地方被顛覆，不理解的環節逐漸清晰，越琢磨越會發現性能測試的有趣。

如文中觀點有理解不到位的地方，歡迎你們一塊兒探討指正。

參考文獻

性能測試解惑之併發壓力
http://www.cnblogs.com/pohome/articles/2073283.html

軟件性能測試流程簡介
http://wenku.baidu.com/link?url=9vfFqnNCsJ3Nv0cAl8_nb9SefIN17TFskt02E0yu75Zk6XVcHEz21rfrKrSfIFi7WhSqOWjsvz1k9fnVZ8SNn1GFbDpzjIzOWjBID1NfmOC

軟件性能設計與評價
http://www.doc88.com/p-331430307121.html

Method for Estimating the Number of Concurrent Users
http://wenku.baidu.com/link?url=w6eahwDiL_7Fyv5ekbpDGj946jICLtWyc7PphU63t7Mu8u84jdlGIMJSpBaxySUH49bU648a-1Y_xap9iSR4vuO1bMdYBOLhYdntDzyrRB7

---

更多精彩內容歡迎關注騰訊優測的微信公衆帳號：

騰訊優測是專業的移動雲測試平臺，爲應用、遊戲，H5混合應用的研發團隊提供產品質量檢測與問題解決服務。不只在線上平臺提供「全面兼容測試」、「雲手機」等多種質量檢測工具，同時在線下爲VIP客戶配備專家團隊，提供定製化綜合測試解決方案。真機實驗室配備上千款手機，覆蓋億級用戶，7*24小時在線運行，爲各種測試工具提供支持。