本文來自于騰訊bugly開發(fā)者社區(qū)，非經(jīng)作者同意，請勿轉(zhuǎn)載，原文地址：http://dev.qq.com/topic/580d914e07b7fc1c26a0cf7c

前言

隨著部門業(yè)務的拓展，我們有了很多性能測試的機會，但在實戰(zhàn)中，慢慢發(fā)現(xiàn)，我們對性能測試的理解并不如自己想的那么清晰，對基本概念和理論的混淆，導致對測試結果的不夠自信，測試過程也常會面臨質(zhì)疑。

所以這一次，我們不說性能測試怎么做，先一起梳理下性能測試的基本理論，分析這些理論如何在壓測工具中產(chǎn)生影響。

系統(tǒng)性能描述

描述一個系統(tǒng)的性能從來不是一句話或是一個數(shù)值的事。

在IEEE的定義中：性能是系統(tǒng)或組件在給定約束中實現(xiàn)的指定功能的程度，諸如速度、正確性、內(nèi)存使用等。

所以性能測試報告中，對系統(tǒng)性能的描述應該是多方面的，如：執(zhí)行效率、穩(wěn)定性、兼容行、可靠性、可擴展性容量等；其中，執(zhí)行效率通過并發(fā)用戶數(shù)、響應時間、吞吐量、成功率、資源消耗綜合體現(xiàn)。

并發(fā)測試

性能測試有：負載測試、壓力測試、配置測試、并發(fā)測試、容量測試、穩(wěn)定性測試。

其中，并發(fā)測試是測試多個用戶同時訪問同一個應用、同一個模塊或者數(shù)據(jù)記錄時是否存在死鎖或者其他性能問題。

在實際的壓測中，我們基本上都是設置多個并發(fā)，再進行負載測試、壓力測試等，因為現(xiàn)實中，我們的系統(tǒng)就是面對多個用戶的同時使用，并且，并發(fā)用戶的數(shù)量，直接影響著系統(tǒng)資源的消耗，例如cpu、mem、網(wǎng)絡連接、帶寬，甚至于系統(tǒng)內(nèi)部邏輯。

并發(fā)怎么看？

所謂并發(fā)，它的特點是“并行”和“同時”。

LoadRuner的并發(fā)很好理解，就是虛擬用戶數(shù)。因為LR有個集合點，可以在所有虛擬用戶初始化且到達集合點后，再一起執(zhí)行后續(xù)操作，從而達到同時且并行的效果。

但目前在后臺性能測試，我們自己開發(fā)的工具大多不帶集合點功能，這時候使用者對并發(fā)的理解就會有點混亂。下面以長連接壓測為例：

最簡單的一種，一個單進程單線程send工具，啟動一次連續(xù)發(fā)m個包，這種其實屬于單并發(fā)，請求串是一個接一個串行到達壓測對象，一般都要再簡單封裝下，類似多進程并發(fā)：

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

注意這樣還是串行執(zhí)行，下面這種才能起到并發(fā)的作用。

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

另一種是單進程多線程模式，可以配置起多個線程，一個線程發(fā)起一個連接到達壓測對象，n個線程就有n個連接，

還有一種，連接池模式，線程與連接數(shù)并不一一對應，維持工具到壓測對象的連接數(shù)不變，線程們從連接池挑選空閑的連接持續(xù)發(fā)送請求。

以上三種情況，假設所有線程極致同步且系統(tǒng)性能足夠，那么同一時間內(nèi)（或者說同一瞬間），應該是有等同線程個數(shù)的請求同時到達系統(tǒng)，并同時被處理完再一起返回，此時線程就是并發(fā)，線程數(shù)就是并發(fā)數(shù)，這里理解應該沒有問題。

但實際上，所有的并發(fā)不可能做到完全同步，壓測過程中由于各種影響，比如：各線程初始化速度不一樣，連接數(shù)不夠，處理速度不一樣等，導致在并行節(jié)奏上相互有了偏差， 這種現(xiàn)象在系統(tǒng)接近性能瓶頸時，會更加突出。所以會有同學疑問，這還能叫“并發(fā)”嗎？ 這里引入“狹義并發(fā)”和“廣義并發(fā)”的概念。

廣義的并發(fā)實際上是在一個時間內(nèi)操作事務的虛擬用戶，而狹義的并發(fā)指的是單位時間內(nèi)向系統(tǒng)發(fā)起請求的虛擬用戶，前者是“存在”，后者是“請求”，勿容置疑，壓力不僅僅受成功發(fā)出請求的用戶帶來的壓力，同時也受“存在”的用戶影響。

這樣看來，工具中的線程數(shù)設置，更偏像是廣義并發(fā)，代表著在壓測時間段內(nèi)虛擬用戶總數(shù)，這也是并發(fā)原始值。而在后續(xù)的壓測過程中，在單位時間內(nèi)，并發(fā)數(shù)可能會動態(tài)變化，這里是狹義并發(fā)。

當工具產(chǎn)生的壓力遠未到系統(tǒng)性能瓶頸時，理論上，狹義并發(fā)=廣義并發(fā)=工具線程數(shù)；當壓力增加，系統(tǒng)響應時間增長，部分線程的請求處理正常，部分線程可能請求超時，那么同一單位時間內(nèi)，同時向系統(tǒng)發(fā)起請求的用戶數(shù)就不等于線程數(shù)了。

那么我們?nèi)绾螌崟r掌握壓測過程中可能變化的并發(fā)？

《Method for Estimating the Number of Concurrent Users》一文介紹了一種并發(fā)估算法（網(wǎng)上有很多相關資料，這里不再累述）：

C：并發(fā)n：壓測時間段內(nèi)所有的請求數(shù)L：平均響應時間T：壓測總時長這里注意：L（平均響應時間）≠ T（總時長）/ n（總請求）

壓力是什么？

壓力就是并發(fā)在單位時間內(nèi)對壓測對象的請求數(shù)。在我們的壓測工具中，有一個配置項專門用來設置壓力，可能是所有線程產(chǎn)生的總壓力，也可能是單個線程產(chǎn)生的壓力。

有些同學會在這里納悶，為什么我設置了發(fā)送10w筆/s的請求，系統(tǒng)吞吐量的計算只有1w筆/s，是不是工具有問題？這里是因為混淆了壓力和性能。

壓力不等于性能，壓力只是檢驗性能的一種手段，對一個性能良好的系統(tǒng)，在一定的壓力下，應該可以保持正常運轉(zhuǎn)，如果超過負荷，則應該分流或化解壓力，這也是我們需要檢驗的

例如：100個并發(fā)，1s內(nèi)發(fā)送1w筆請求，如果系統(tǒng)的吞吐量計算大于或等于1w筆/s，說明系統(tǒng)承受住100個并發(fā)，1w/s的壓力，我們可以增加壓力繼續(xù)測試，直到出現(xiàn)性能拐點；如果系統(tǒng)的吞吐量計算是5k筆/s，則說明，如果我們需要系統(tǒng)應付100個并發(fā)，1w/s的壓力，解決方案要么提升系統(tǒng)性能一倍，要么擴容一臺分流壓力。

要特別注意：壓力是由工具制造，工具的最大性能決定施加的最大壓力。我們在測試過程中曾經(jīng)遇到壓測系統(tǒng)還沒到極限，工具已經(jīng)到瓶頸的情況，這時候得到的壓測數(shù)據(jù)是錯誤的。

吞吐量如何計算？

我們在壓測工具制作中，一直存在一個爭議——吞吐量的計算。

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

公式1： 吞吐量=并發(fā)數(shù)/平均響應時間公式2： 吞吐量=請求總數(shù)/總時長

公式1、2大家應該都接觸過，雖然看上去不一樣，其實理論上都是ok的。

首先我們可以從C = nL / T 推導：

并發(fā) = 請求總數(shù)*平均響應時間 / 總時長=》并發(fā) / 平均響應時間 = 請求總數(shù) / 總時長=》公式1 = 公式2

然后我們構建三組模型進一步論證：

第一組模型

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

公式1：平均響應時間 = （1+1+1+2）/ 4= 1.25s ;并發(fā) = nL/T =4*1.25/2 =2.5吞吐量 = 2.5 / 1.25 = 2 筆/s公式2：吞吐量 = 總筆數(shù)/總耗時 = 4/2= 2 筆/s

第二組模型

一共有4個線程，同時發(fā)了4筆請求，4筆請求耗時均為1s，1s內(nèi)全部發(fā)送完畢。

公式1：平均響應時間 = （1+1+1+1）/ 4= 1s并發(fā) = nL/T =4*1/1 =4吞吐量 = 4 / 1= 4 筆/s公式2：吞吐量 = 總筆數(shù)/總耗時 = 4 / 1= 4 筆/s

第三組模型

一共有4個線程，4筆請求耗時均為1s，但線程發(fā)送出現(xiàn)不同步現(xiàn)象，一共持續(xù)1.5s完成全部：

公式1：平均響應時間 = （1+1+1+1）/ 4= 1s并發(fā) = nL/T =4*1/1 =4吞吐量 = 4 / 1.5= 2.67 筆/s公式2：吞吐量 = 總筆數(shù)/總耗時 = 4 / 1.5 = 2.67 筆/s

從我們構建的模型上看，兩個公式計算的結果是相等的。但是，這種平衡是建立在并發(fā)穩(wěn)定的基礎上，并發(fā)如果變化，結果就會有差異。下面我們看一組真實的壓測數(shù)據(jù)

從上圖中看出，實際壓測時，兩個公式還是會有些微差別，這就是因為我們本來預想并發(fā)應該=工具線程數(shù)，但在壓測過程中，實際并發(fā)發(fā)生了變化，我們再反推下實際的并發(fā)數(shù)

計算出的實際并發(fā)確實稍低于工具線程數(shù)。

結論

在單接口壓測時，我們用“請求總數(shù)/總時長”得到吞吐量；然后再用“吞吐量/平均響應時間”得到實際并發(fā)，此舉可用來觀察系統(tǒng)實際承受的并發(fā)；

在多接口壓測時，由于短板效應，同一個流程中的所有接口獲得的請求總數(shù)和總時長都一樣，顯然“請求總數(shù)/總時長”計算各個子接口的吞吐量不合適，所以改用“并發(fā)/平均響應時間”，其中的并發(fā)數(shù)應在壓測工具中埋點統(tǒng)計，不可簡單使用工具線程數(shù)。

結語

在性能測試平臺的開發(fā)中，為了測試結果更接近現(xiàn)實，我們在吞吐量計算上改過三個版本，小伙伴們也有過幾次激烈的討論，正是對這種小細節(jié)的不斷糾纏，我們對性能測試的認識也在不斷刷新，原本以為正確的地方被顛覆，不理解的環(huán)節(jié)逐漸清晰，越琢磨越會發(fā)現(xiàn)性能測試的有趣。

如文中觀點有理解不到位的地方，歡迎大家一起探討指正。

參考文獻

性能測試解惑之并發(fā)壓力
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

---

更多精彩內(nèi)容歡迎關注騰訊優(yōu)測的微信公眾賬號：

騰訊優(yōu)測是專業(yè)的移動云測試平臺，為應用、游戲，H5混合應用的研發(fā)團隊提供產(chǎn)品質(zhì)量檢測與問題解決服務。不僅在線上平臺提供「全面兼容測試」、「云手機」等多種質(zhì)量檢測工具，同時在線下為VIP客戶配備專家團隊，提供定制化綜合測試解決方案。真機實驗室配備上千款手機，覆蓋億級用戶，7*24小時在線運行，為各類測試工具提供支持。

轉(zhuǎn)載于:https://www.cnblogs.com/bugly/p/5992905.html

總結

以上是生活随笔為你收集整理的【腾讯优测干货分享】从压测工具谈并发、压力、吞吐量的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。