并發(fā)數(shù)，線程數(shù)，吞吐量，每秒事務數(shù)（TPS）都是性能測試領域非常關鍵的數(shù)據(jù)和指標。

那么他們之間究竟是怎樣的一個對應關系和內在聯(lián)系？

測試時，我們經常容易將線程數(shù)等同于表述為并發(fā)數(shù)，這一表述正確嗎？

本文就將對性能領域的這些關鍵概念做一次探討。

文章可能會比較長，希望您保持耐心看完。

1. 走進開封菜，了解性能

①老王開了家餐廳

我們的主角老王

，在M市投資新開業(yè)了一家，前來用餐的顧客絡繹不絕：

餐廳里有4種不同身份的人員：

?文章來源地址http://www.zghlxwxcb.cn/news/detail-770778.html

用戶一次完整的用餐流程如下：

顧客到店小二處付款點餐 => 小二將訂單轉發(fā)給后廚 => 后廚與備菜工配合，取材完成烹飪后交給小二 => 小二上菜，顧客用餐。

假設所有顧客都不堂食而是打包帶走，也就是不考慮用戶用餐時間。餐廳完成一次訂單的時間是多久？

訂單時間 = 顧客點單時間 + 前臺接收轉發(fā)時間 + 后廚取材烹飪時間 + 后廚交給服務員，服務員上菜時間。

說白了就是每個流程的耗時相加。

假設以上時間分別為1，1，5，1（分鐘），那么一次訂單的完成時間就是8分鐘。

??

②問題來了

餐廳當然不可能只有一個人就餐，否則老王不要帶著小姨子跑路。

所以我們接下來看多人就餐的情況。

假設同一時間點上有兩人

就餐，會發(fā)生什么情況？

第一位用戶與第一個場景一樣，仍然是點單-下單-烹飪-上菜，8分鐘后第一位顧客拿著打包的食物離開。

第二位用戶則有所不同了。假設小二，廚師，備菜都只有一人，而且他們每個人同時只能處理一件事情。

那么第二位用戶首先需要在點餐時等待小二1分鐘，而后廚師烹飪第一位用戶的菜時，沒有任何人在為他服務。

我們來梳理一下這個過程中，每一分鐘都發(fā)生了什么事情：

?

可以看到，兩個顧客完成訂單的總時長是13分鐘。

繼續(xù)推算我們發(fā)現(xiàn)，每增加一人總時長增加5分鐘。

在當前的人員配置下，顧客越多，后來的顧客等待時間就越長。

③這還不是高峰期

如果餐廳在高峰時段只有兩人用餐，那估計老王還得帶著小姨子跑路。

實際一個運營得當?shù)拈_封菜餐廳，在用餐高峰時段的顧客數(shù)可能高達百人。

那么問題來了，在某個普通工作日，12：00午飯時間，帶著各種工牌的IT男女顧客蜂擁而至，餐廳瞬間擠進來一百人。

這個時候會發(fā)生什么？

現(xiàn)在餐廳已經完全服務不過來了，后續(xù)的顧客等的時間越來越長，最后一位可憐的顧客要等到差不多晚上8點才能吃到飯。

這顯然是不可能的，實際上等了不到半個小時吃不上飯的顧客就都要走光了。

老王開始考慮如何應對營業(yè)高峰期的情況。

經過上面的分析，老王發(fā)現(xiàn)，增加各崗位人手無疑是最直觀的解決辦法！

我們可以計算一下人手增加的情況。假設把所有人員增加為2人配置：

??

那么很簡單，2人就餐的情況下，由于所有人員并行服務，就餐的兩名顧客可以同一時間點餐，等待烹飪，上菜后打包走人。

而后來的客人可以看作兩條并行的線，那么100顧客的用餐時間就很自然的減半了。

看到這里，終于出現(xiàn)“并行”的概念了。

??

④繼續(xù)調優(yōu)

通過double人員配置，老王成功的使得用餐高峰期的服務能力提高了一倍，但這還不夠。這種情況下，服務100顧客仍需差不多4個小時。

老王再次思考整個服務團隊的配置和各環(huán)節(jié)處理能力，他發(fā)現(xiàn)，其瓶頸就在于“后廚”。顧客的等待時間，大部分都是在等待烹飪。

那么增加后廚能力就是重中之重，老王繼續(xù)做了一系列措施：

• 再次double大廚人數(shù)，現(xiàn)在廚師們四個人同時并行做菜。
• 讓備菜員提前將熱門食材準備好。
• 聘請更有經驗的大廚，每個餐品烹飪時間更快，加上提前備菜，整個配餐時間縮短到2分鐘。
• 將點餐的過程改為使用手機小程序下單，讓小二專注于上菜。

整個團隊配置變?yōu)椋?/p>

?如此配置之下，這家開封菜終于可以在1小時之內就完成對100人顧客的就餐服務了！

2. 這并不是一篇餐飲管理文章

再繼續(xù)討論餐廳的服務能力調優(yōu)，這可能就要變成一片餐飲博文了。

不過相信敏銳的你能看出來，第一部分我們的討論里，包含了大量與服務器性能相似的概念。

恰好，老王

除了開了一家開封菜餐廳，還運營著一家網站=_=!。

這家網站的一次典型事務請求鏈路是這樣的：

你別說，還真挺像用餐流程的吧。

而且就像多人用餐的場景一樣，這個網站同樣也有多用戶請求的情況：

當一條請求從客戶端發(fā)起時，它遵循著以上的線路傳遞，線性完成。

老王發(fā)現(xiàn)，這家網站的性能關鍵，在于應用服務器上。就像餐廳的服務能力，主要取決于后廚團隊一樣。

當多個客戶端同時發(fā)起請求時，服務器必須具備一定的“并行”能力，否則后續(xù)進來請求會排隊而且可能超時。

說到這呢，雖然上圖我們畫的是一個

，但一般都服務器的都有多處理器,輔以超線程技術。

而主流編程語言都有“多線程編程”的概念，其目的就在于合理的調度任務，將CPU的所有處理器充分的利用起來。

也就是說我們可以認為，這套應用服務本身就有不止一個“大廚”在烹飪。

取決于處理器數(shù)和多線程技術，數(shù)個事務可以以線程

的方式并行處理。

不過老王對于當前服務器的性能并不滿意，就像對于餐廳一樣，老王也針對這個應用服務思考了更多調優(yōu)方案：

• 大廚的數(shù)量真的夠嗎？是不是要繼續(xù)增加人數(shù)（CPU核數(shù)，服務器節(jié)點數(shù)-硬件調優(yōu)）？
• 大廚的經驗和技術到位嗎？是不是要改聘更資深的大廚（改換具有更高頻CPU的服務器-硬件調優(yōu)；調整業(yè)務邏輯效率-邏輯調優(yōu)）？
• 改良熱門餐品的備菜策略？（利用數(shù)據(jù)庫索引、緩存等技術-邏輯調優(yōu)）

除了我們強調的調優(yōu)重點，應用服務/后廚團隊，其他部分也是有可能成為瓶頸，需要調優(yōu)解決的，比如：

• 餐廳容量會不會無法容納排隊的客戶？（服務器容量，線程池大小，最大連接數(shù)，內存空間）
• 小二的下單和上菜速度有沒有成為掣肘？（網絡帶寬，路由效率等。對于數(shù)據(jù)密集型服務而言，網絡帶寬很可能成為瓶頸。）
• 等等

??

3. 下面是性能測試環(huán)節(jié)

接下來我們要討論如何測試一套服務的性能。

線程數(shù)：

要實現(xiàn)性能測試的一個必要條件，那就是我們必須要能模擬高峰期的訪問量。這一點通過正常的應用客戶端是很難辦到的（比如web應用的客戶端就是瀏覽器，你很難用瀏覽器并發(fā)向服務器發(fā)送大量請求）。

這里就需要性能測試工具來幫忙了，主流的性能測試工具比如

，等都能以線程式并發(fā)的方式，幫我們達成“短時間內向服務器發(fā)送大量請求”這一任務。

多線程式并發(fā)測試工具，顧名思義，會啟動復數(shù)個線程，讓每個線程獨立向服務器端發(fā)出請求。

有時候我們在描述性能測試過程時，會將這個客戶端的獨立線程數(shù)表述為“并發(fā)數(shù)”。

但是注意，這里的“并發(fā)”指的是客戶端并發(fā)，很簡單，客戶端能發(fā)出很多請求，服務器卻未必能處理得了是不是？

并行數(shù)：

那么服務器一次性能同時處理多少事務請求呢？

根據(jù)我們之前的討論，同一時間節(jié)點上同時處理的事務數(shù)最大就是：CPU處理器數(shù)*服務器超線程倍率。

比如對于一個8核未超線程CPU，某時間節(jié)點上的同時處理的事務不會超過8個。類比于8個廚師，同一時間點上只能處理8份餐品。

而超線程技術就像是給廚師們來了一場“左右互搏”培訓，讓每個人都能一心二用，一次處理2份餐品。

這里我們描述的“同時8個”事務，就是“并行/平行”的含義。

并發(fā)數(shù)：

注意上面我們討論的“并行數(shù)”，不是"并發(fā)數(shù)"。否則我們直接看CPU核數(shù)就能確定并發(fā)數(shù)了。

并發(fā)數(shù)指的是一個時間段內

的事務完成數(shù)。這個切片“時間段”常取1秒鐘或1分鐘這樣的整數(shù)來做換算。

假設一個廚師平均2分鐘做完一道菜，那么8個廚師2分鐘完成8道菜，換算一下就是4道/分鐘。

如果以分鐘為單位進行統(tǒng)計，那么這個數(shù)字就是最終結果。

每秒事務數(shù)（TPS）：

一般應用服務器的處理速度跟廚師做菜是不在一個數(shù)量級的，常見的事務請求在應用服務器端的處理時間以毫秒為單位計算。

所以測試性能時，我們更常用“1秒鐘”來作為切片時間段。

一秒鐘完成多少個事務請求，這個數(shù)據(jù)就是我們耳熟能詳?shù)摹懊棵胧聞諗?shù)”。

這個指標翻譯成英文就是TPS?- Transaction Per Seconds。（也有用QPS - Query Per Seconds來統(tǒng)計的，其差異暫時不做討論了）

每秒事務數(shù)，就是衡量服務器性能的最重要也是最直觀指標。

每秒能完成的事務數(shù)越多，那么每分鐘能完成的事務就越多，每天完成的事務數(shù)就越多 --?

簡單的小學數(shù)學。

那么他直接能影響到一個應用服務每天平均能承受的訪問量/請求量，以及業(yè)務高峰期能承受的壓力。

平均響應時間：

那么有哪些因素會影響到TPS數(shù)值？

有兩個主要的維度：

• 單個事務響應速度
• 同一時間能并行執(zhí)行的事務

第二點我們說了，它主要跟服務器資源配置，線程池容量，線程調度等相關。

第一點換一個說法就是：事務平均響應時間。單個事務平均下來完成的速度越快，那么單位時間內能完成的事務數(shù)就越多，TPS就越高 --?

簡單的小學數(shù)學。

所以在進行性能調優(yōu)時，除了服務器容量資源，單個事務響應速度是另一個關注的重點。

要關注事務響應速度/時間，可以考慮在事務內部邏輯節(jié)點添加“耗時探針”的方式，來探測每個步驟分別花費的時間，從而找出可優(yōu)化的部分。

吞吐量

吞吐量

是在性能探測過程中經常冒出來的名詞，怎么理解他呢？

簡單的結論就是，吞吐量是站在“量”的角度去度量，是一個參考指標。

但是光有“量”的數(shù)據(jù)有時候并無太大價值，一家餐廳1個小時賣出100份餐品和一個月才賣出100份餐品，單從“量”的維度衡量肯定不行，時間維度很重要！

所以，性能測試領域的吞吐量通常會結合上時間維度進行統(tǒng)計。

如果吞吐量的“量”以“事務”為統(tǒng)計單位的話，結合時間維度，轉化以后可以很容換算成TPS。

4. 最后，關于性能測試的一些碎碎念

測試類型

由于測試目標的不同，性能測試可能存在很多種形式。

比如明確了解日訪問量和巔峰訪問量，測試服務器是否能夠承受響應壓力的測試。

比如用于探測系統(tǒng)負載極限和性能拐點的測試。

比如衡量系統(tǒng)在高負載情況下，長時間運行是否穩(wěn)定的測試。

這許多種形式我們暫且不做討論，不過所有以上測試的基礎都是它 -- “并發(fā)測試”。

制造并發(fā)，是性能測試的基本實現(xiàn)辦法。

進一步細化理解客戶端線程數(shù)和并發(fā)量的關系

設服務器并發(fā)能力為每秒完成1個事務，即TPS=1/s。且服務器使用單核處理器，現(xiàn)用Jmeter啟動5個線程循環(huán)進行并發(fā)測試，那么每個切片時間（每秒）都發(fā)生了什么？

我們可以用如下圖表來分析：

其中，

為線程可執(zhí)行（等待執(zhí)行），為線程正在執(zhí)行，表示線程執(zhí)行完畢。

假設其他條件不變，增加服務器并行處理數(shù)為2（增加CPU核數(shù)為2，以及合理的線程調度機制）那么變?yōu)椋?/p>

這里真實的并發(fā)數(shù)（服務器單位時間完成的事務數(shù)）就是圖中每一秒鐘完成的事務數(shù)。

而客戶端啟動的其他未處理的線程則在“排隊等待”。

線程并發(fā)數(shù)量

那么制造多少并發(fā)，換言之，我應該用多少并發(fā)線程數(shù)去進行測試？

實際上客戶端發(fā)起的線程數(shù)與服務器可達到的并發(fā)數(shù)并無直接關系，但你應該使用足夠的線程數(shù)，讓服務器達到事務飽和。

如何判斷服務器是否達到飽和？這時我們可以采取階梯增壓

的方式，不斷加大客戶端線程數(shù)量，直到服務器處理不過來，事務頻繁超時，這時就得到了服務器處理能力極限。

根據(jù)不同的測試類型，取這個極限數(shù)量的一定百分比作為客戶端線程數(shù)。

比如說，負載測試中，通常取達到這個極限數(shù)值的70%。

客戶端損耗

我們在討論餐廳訂單流程和服務器事務流程時，流程圖里包括了顧客/客戶端。

顧客點餐要不要花時間？當然要，如果他患上選擇困難癥，甚至有可能在下單的時候花去大量時間。

同理，客戶端從啟動線程到構造請求并發(fā)出，這一過程也有一定的時間損耗。

通常在測試服務器性能的時候，客戶端性能是應該被剝離出去的，所以測試時應該盡量降低客戶端時間損耗。

• 適當增加客戶端線程循環(huán)次數(shù) - 稀釋這些線程啟動的占用時間
• 當客戶端線程數(shù)需要較大數(shù)量時（對jmeter而言，超過1000左右），客戶機/測試機的資源占用會增大，整個客戶端的請求構造時間會拉長。應該考慮分布式測試。
• 盡量減少客戶端請求構造時間，比如beanshell請求加密，如果過程過于復雜也會耗去可觀時間。極限測試情況下應考慮簡化。

那么本文到這里告一段落。

希望能幫助理解性能測試領域的這些關鍵概念和原理。

最后：下方這份完整的軟件測試視頻學習教程已經整理上傳完成，朋友們如果需要可以自行免費領取 【保證100%免費】

?

到了這里，關于性能測試：深入理解并發(fā)量，線程數(shù)，吞吐量，TPS的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！