6{icon} {views}
併發數，線程數，吞吐量，每秒事務數（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請求加密，如果過程過於複雜也會耗去可觀時間。極限測試情況下應考慮簡化。
那麼本文到這裏告一段落。
希望能幫助理解性能測試領域的這些關鍵概念和原理。
,再繼續討論餐廳的服務能力調優，這可能就要變成一片餐飲博文了。
不過相信敏銳的你能看出來，第一部分我們的討論里，包含了大量與服務器性能相似的概念。
恰好，老王除了開了一家開封菜餐廳，還運營着一家網站=_=!。
這家網站的一次典型事務請求鏈路是這樣的：
你別說，還真挺像用餐流程的吧。
而且就像多人用餐的場景一樣，這個網站同樣也有多用戶請求的情況：
當一條請求從客戶端發起時，它遵循着以上的線路傳遞，線性完成。
老王發現，這家網站的性能關鍵，在於應用服務器上。就像餐廳的服務能力，主要取決於後廚團隊一樣。
當多個客戶端同時發起請求時，服務器必須具備一定的“并行”能力，否則後續進來請求會排隊而且可能超時。
說到這呢，雖然上圖我們畫的是一個，但一般都服務器的都有多處理器,輔以超線程技術。
而主流編程語言都有“多線程編程”的概念，其目的就在於合理的調度任務，將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請求加密，如果過程過於複雜也會耗去可觀時間。極限測試情況下應考慮簡化。
那麼本文到這裏告一段落。
希望能幫助理解性能測試領域的這些關鍵概念和原理。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【精選推薦文章】
智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選
想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計
帶您來看台北網站建置，台北網頁設計，各種案例分享
廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益
