併發數,線程數,吞吐量,每秒事務數(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網頁設計已成為網頁設計推薦首選
想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計
帶您來看台北網站建置,台北網頁設計,各種案例分享
廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益