併發數，執行緒數，吞吐量，每秒事務數（TPS）都是效能測試領域非常關鍵的資料和指標。

那麼他們之間究竟是怎樣的一個對應關係和內在聯絡？

測試時，我們經常容易將執行緒數等同於表述為併發數，這一表述正確嗎？

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

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

1. 走進開封菜，瞭解效能

①老王開了家餐廳

我們的主角老王 ，在M市投資新開業了一家 ，前來用餐的顧客絡繹不絕：

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

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

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

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

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

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

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

②問題來了

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

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

假設同一時間點上有兩人 就餐，會發生什麼情況？

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

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

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

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

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

繼續推算我們發現，每增加一人總時長增加5分鐘。

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

③這還不是高峰期

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

實際一個運營得當的開封菜餐廳，在用餐高峰時段的顧客數可能高達百人。

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

這個時候會發生什麼？

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

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

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

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

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

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

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

看到這裡，終於出現“並行”的概念了。

④繼續調優

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

老王再次思考整個服務團隊的配置和各環節處理能力，他發現，其瓶頸就在於“後廚”。顧客的等待時間，大部分都是在等待烹飪。

那麼增加後廚能力就是重中之重，老王繼續做了一系列措施：

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

整個團隊配置變為：

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

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

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

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

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

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

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

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

老王發現，這家網站的效能關鍵，在於應用伺服器上。就像餐廳的服務能力，主要取決於後廚團隊一樣。

當多個客戶端同時發起請求時，伺服器必須具備一定的“並行”能力，否則後續進來請求會排隊而且可能超時。

說到這呢，雖然上圖我們畫的是一個 ，但一般都伺服器的 都有多處理器,輔以超執行緒技術。

而主流程式語言都有“多執行緒程式設計”的概念，其目的就在於合理的排程任務，將CPU的所有處理器充分的利用起來。

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

取決於處理器數和多執行緒技術，數個事務可以以執行緒 的方式並行處理。

不過老王對於當前伺服器的效能並不滿意，就像對於餐廳一樣，老王也針對這個應用服務思考了更多調優方案：

• 大廚的數量真的夠嗎？是不是要繼續增加人數（CPU核數，伺服器節點數-硬體調優）？
• 大廚的經驗和技術到位嗎？是不是要改聘更資深的大廚（改換具有更高頻CPU的伺服器-硬體調優；調整業務邏輯效率-邏輯調優）？
• 改良熱門餐品的備菜策略？（利用資料庫索引、快取等技術-邏輯調優）

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

• 餐廳容量會不會無法容納排隊的客戶？（伺服器容量，執行緒池大小，最大連線數，記憶體空間）
• 小二的下單和上菜速度有沒有成為掣肘？（網路頻寬，路由效率等。對於資料密集型服務而言，網路頻寬很可能成為瓶頸。）
• 等等

3. 下面是效能測試環節

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

執行緒數：

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

這裡就需要效能測試工具來幫忙了，主流的效能測試工具比如 ， 等都能以執行緒式併發的方式，幫我們達成“短時間內向伺服器傳送大量請求”這一任務。

多執行緒式併發測試工具，顧名思義，會啟動複數個執行緒，讓每個執行緒獨立向伺服器端發出請求。

有時候我們在描述效能測試過程時，會將這個客戶端的獨立執行緒數表述為“併發數”。

但是注意，這裡的“併發”指的是客戶端併發，很簡單，客戶端能發出很多請求，伺服器卻未必能處理得了是不是？

並行數：

那麼伺服器一次效能同時處理多少事務請求呢？

根據我們之前的討論，同一時間節點上同時處理的事務數最大就是：CPU處理器數*伺服器超執行緒倍率。

比如對於一個8核未超執行緒CPU，某時間節點上的同時處理的事務不會超過8個。類比於8個廚師，同一時間點上只能處理8份餐品。

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

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

併發數：

注意上面我們討論的“並行數”，不是"併發數"。否則我們直接看CPU核數就能確定併發數了。

併發數指的是一個時間段內 的事務完成數。這個切片“時間段”常取1秒鐘或1分鐘這樣的整數來做換算。

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

如果以分鐘為單位進行統計，那麼這個數字就是最終結果。

每秒事務數（TPS）：

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

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

一秒鐘完成多少個事務請求，這個資料就是我們耳熟能詳的“每秒事務數”。

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

每秒事務數，就是衡量伺服器效能的最重要也是最直觀指標。

每秒能完成的事務數越多，那麼每分鐘能完成的事務就越多，每天完成的事務數就越多 -- 簡單的小學數學。

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

平均響應時間：

那麼有哪些因素會影響到TPS數值？

有兩個主要的維度：

• 單個事務響應速度
• 同一時間能並行執行的事務

第二點我們說了，它主要跟伺服器資源配置，執行緒池容量，執行緒排程等相關。

第一點換一個說法就是：事務平均響應時間。單個事務平均下來完成的速度越快，那麼單位時間內能完成的事務數就越多，TPS就越高 -- 簡單的小學數學。

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

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

吞吐量

吞吐量 是在效能探測過程中經常冒出來的名詞，怎麼理解他呢？

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

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

所以，效能測試領域的吞吐量通常會結合上時間維度進行統計。

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

4. 最後，關於效能測試的一些碎碎念

測試型別

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

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

比如用於探測系統負載極限和效能拐點的測試。

比如衡量系統在高負載情況下，長時間執行是否穩定的測試。

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

製造併發，是效能測試的基本實現辦法。

進一步細化理解客戶端執行緒數和併發量的關係

設伺服器併發能力為每秒完成1個事務，即TPS=1/s。且伺服器使用單核處理器，現用Jmeter啟動5個執行緒迴圈進行併發測試，那麼每個切片時間（每秒）都發生了什麼？

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

其中， 為執行緒可執行（等待執行）， 為執行緒正在執行， 表示執行緒執行完畢。

假設其他條件不變，增加伺服器並行處理數為2（增加CPU核數為2，以及合理的執行緒排程機制）那麼變為：

這裡真實的併發數（伺服器單位時間完成的事務數）就是圖中每一秒鐘完成的事務數。

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

執行緒併發數量

那麼製造多少併發，換言之，我應該用多少併發執行緒數去進行測試？

實際上客戶端發起的執行緒數與伺服器可達到的併發數並無直接關係，但你應該使用足夠的執行緒數，讓伺服器達到事務飽和。

如何判斷伺服器是否達到飽和？這時我們可以採取階梯增壓 的方式，不斷加大客戶端執行緒數量，直到伺服器處理不過來，事務頻繁超時，這時就得到了伺服器處理能力極限。

根據不同的測試型別，取這個極限數量的一定百分比作為客戶端執行緒數。

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

客戶端損耗

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

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

同理，客戶端從啟動執行緒到構造請求併發出，這一過程也有一定的時間損耗。

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

• 適當增加客戶端執行緒迴圈次數 - 稀釋這些執行緒啟動的佔用時間
• 當客戶端執行緒數需要較大數量時（對jmeter而言，超過1000左右），客戶機/測試機的資源佔用會增大，整個客戶端的請求構造時間會拉長。應該考慮分散式測試。
• 儘量減少客戶端請求構造時間，比如beanshell請求加密，如果過程過於複雜也會耗去可觀時間。極限測試情況下應考慮簡化。

那麼本文到這裡告一段落。

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