80后聊架构:架构设计中两个重要指标,延时与吞吐量(Latency vs Throughput) | 架构师之路

科技   2024-11-06 18:08   北京  
《架构师之路:架构设计中的100个知识点》
3.延时与吞吐量

有朋友问我说,架构优化时,什么时候要重点优化延时,什么时候要重点优化吞吐量?
画外音:补充阅读材料在最后。

延时(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。

系统的扩展性,理论上是无限的,架构合理的话,吞吐量可以无限提升,能同时为无限多的用户同时服务。

一句话来回答这个问题:
一个用户慢,就去优化延时。
多个用户扛不住,就去优化吞吐量。

补充阅读材料
23年1月的一篇《延时与吞吐量》。
https://cs.fyi/guide/latency-vs-throughput

分为几章:
1. 延时
2. 吞吐量
3. 延时与吞吐量的关系
4. Web Server举例
5. Database举例
6. 总结

文章不长,10分钟能读完。

==全文完==

后续我将以短视频+图文+直播+星球社群的形式,系统性的分享架构设计中的100个相关知识点,欢迎感兴趣的童鞋关注。
画外音:均免费。


短视频的进度会快一些,码字有点麻烦,进度会慢一些,大伙静候。
第2集:究竟怎么做架构设计?

回归本心,希望为社区贡献自己的一小点力量。


平台的策略,专业内容不推流,大家多帮忙标星以及点赞,转发,在看连。感谢。

架构师之路
架构师之路,坚持撰写接地气的架构文章
 最新文章