80后聊架構:架構設計中兩個重要指標,延時與吞吐量(Latency vs Throughput) | 架構師之路
《架構師之路:架構設計中的100個知識點》三:延時與吞吐量
有朋友問我說,架構優化時,什么時候要重點優化延時,什么時候要重點優化吞吐量?
畫外音:補充閱讀材料在最后。
延時(Latency)與吞吐量(Throughput)是架構設計中非常重要,又非常容易搞混的兩個指標。
什么是延時?
延時是指完成某個動作所需要的時間。
返回一個HTTP請求的時間是200毫秒,我們說請求的延時是200毫秒。
生一個孩子的時間是10個月,我們說生孩子延時是10個月。
什么是吞吐量?
吞吐量是指單位時間內完成某個動作的次數。
一個請求的處理時間是200毫秒,單線程每秒鐘可以處理5個請求,我們就說其的吞吐量是每秒5次。
10個月能生一個孩子,我們就說生孩子的吞吐量是每10月1個。
延時和吞吐量有什么關系?
一般來說,降低延時可以提升吞吐量。
例如:200毫秒處理一個請求,優化為100毫秒處理一個請求,吞吐量就由5提升為10了。
但是,不降低延時也可以提升吞吐量。
例如:單線程200毫秒處理一個請求,線程數增加到10,吞吐量就由5提升為50了。
畫外音:假如CPU不是瓶頸。
有時候,延時是很難降低,此時不能靠降低延時增加吞吐量。
例如:生孩子的延時就必須是10個月。
此時,提升吞吐量的方法只能多個家庭并發一起生。
回到開篇的問題,架構優化時,什么時候要重點優化延時,什么時候要重點優化吞吐量?
對于大規模系統的架構設計而言:
- 延時,延時更多是性能(performance)指標,關乎單用戶體驗。
- 吞吐量,吞吐量是擴展性(scalability)指標,關乎同時能服務多少客戶。
系統的性能,是有天花板的,延時不能無限優化,不可能降到0。
系統的擴展性,理論上是無限的,架構合理的話,吞吐量可以無限提升,能同時為無限多的用戶同時服務。
一句話來回答這個問題:
- 一個用戶慢,就去優化延時。
- 多個用戶扛不住,就去優化吞吐量。