1. 程式人生 > >所謂的效能,是負載、吞吐量、可接受的響應時間和資源利用率之間的一種平衡。

所謂的效能,是負載、吞吐量、可接受的響應時間和資源利用率之間的一種平衡。

所謂的效能,是負載、吞吐量、可接受的響應時間和資源利用率之間的一種平衡。

通過一個理髮店的例子,然後引出最佳併發使用者數和最大併發使用者數的概念

背景:理髮店共有3名理髮師,每名理髮師完成一次理髮都耗時1小時,店裡有還有一些位子供客人等位,每個客人在理髮店呆的時間超過3小時就會無法忍受離開。

3名理髮師,好比應用同時能處理幾個事務

理髮耗時1小時,好比完成一次事務需要的時間

(等待位子,加上能剪髮的位子,好比最大請求佇列數)

3小時,好比響應時間,超過3小時,則放棄這個請求

結合場景,從上圖可以看出,隨著理髮店客人的數量增加時,響應時間一開始並沒有明顯變化,因為有3個理髮師,足矣消化掉3個客人,當超過3個客人時,勢必有客人是需要等待的。

在客人數量正好為3人時,理髮師的工作效率最高,客人也不需要等待,這個數我就理解為 最佳併發使用者數

而當客人數為9人時,在這個場景中,勢必有客人完成理髮的時間要達到2-3小時了(來的時候,其他客人已經剪到一半了,需要等正在剪的客人0-1小時,前面排在前面的人理髮1小時,自己理髮1小時),而再來客人的話,必定完成理髮的時間超過3小時,也就是所謂的超時放棄走人了。

這個9,我就理解為 最大併發使用者數。

==================================================

對於一個確定的被測系統來說,在某個具體的軟硬體環境下,它的“最佳併發使用者數”和“最大併發使用者數”都是客觀存在。以“最佳併發使用者數”為例,假如一個系統的最佳併發使用者數是50,那麼一旦併發量超過這個值,系統的吞吐量和響應時間必然會 “此消彼長”;如果系統負載長期大於這個數,必然會導致使用者的滿意度降低並最終達到一種無法忍受的地步。所以我們應該 保證最佳併發使用者數要大於系統的平均負載。

 

要補充的一點是,當我們需要對一個系統長時間施加壓力——例如連續加壓3-5天,來驗證系統的可靠性或者說穩定性時,我們所使用的併發使用者數應該等於或小於“最佳併發使用者數”——大家也可以結合上面的討論想想這是為什麼 ^_^

 

而對於最大併發使用者數的識別,需要考慮和鑑別一下以下兩種情況:

 

1.當系統的負載達到最大併發使用者數後,響應時間超過了使用者可以忍受的最大限度——這個限度應該來源於效能需求,例如:在某個級別的負載下,系統的響應時間應該小於5秒。這裡容易疏忽的一點是,不要把顧客因為無法忍受而離開時店內的顧客數量作為理髮店的“最大併發使用者數”,因為這位顧客是在3小時前到達的,也就是說3小時前理髮店內的顧客數量才是我們要找的“最大併發使用者數”。而且,這位顧客的離開只是一個開始,可能有會更多的顧客隨後也因為無法忍受超長的等待時間而離開;

 

2.在響應時間還沒有到達使用者可忍受的最大限度前,有可能已經出現了使用者請求的失敗。以理髮店模型為例,如果理髮店只能容納6位顧客,那麼當7位顧客同時來到理髮店時,雖然我們可以知道所有顧客都能在可容忍的時間內剪完頭髮,但是因為理髮店容量有限,最終只好有一位顧客打道回府,改天再來。

 

對於一個系統來說,我們應該確保系統的最大併發使用者數要大於系統需要承受的峰值負載。

==================================================

系統吞度量要素:

一個系統的吞度量反映的是伺服器承受的壓力。承壓能力與request對CPU的消耗、外部介面、IO等等緊密關聯。單個reqeust 對CPU消耗越高,外部系統介面、IO影響速度越慢,系統吞吐能力越低,反之越高。

系統吞吐量幾個重要引數:QPS(TPS)、併發數、響應時間

QPS(TPS):每秒鐘request/事務 數量

併發數: 系統同時處理的request/事務數

響應時間: 一般取平均響應時間

 

理解了上面三個要素的意義之後,就能推算出它們之間的關係:

QPS(TPS)= 併發數 / 平均響應時間

一個系統吞吐量通常由QPS(TPS)、併發數兩個因素決定,每套系統這兩個值都有一個相對極限值,在應用場景訪問壓力下,只要某一項達到系統最高值,系統的吞吐量就上不去了,如果壓力繼續增大,系統的吞吐量反而會下降,原因是系統超負荷工作,上下文切換、記憶體等等其它消耗導致系統性能下降。

 

 

參考

衡量網站效能時,併發數與吞吐量為何要分別考量?

聊聊QPS/TPS/併發量/系統吞吐量的概念

系統吞吐量(TPS)、使用者併發量、效能測試概念和公式

從最佳併發使用者數和最大併發使用者數看效能測試