主要观点总结
文章主要介绍了架构设计中的两个重要指标——延时和吞吐量,以及它们在架构优化中的应用。文章还讨论了延时和吞吐量的关系,如何根据不同情况重点优化这两个指标,并通过实际例子进行说明。
关键观点总结
关键观点1: 什么是延时和吞吐量
延时是指完成某个动作所需要的时间,而吞吐量则是指单位时间内完成某个动作的次数。
关键观点2: 延时和吞吐量的关系
一般来说,降低延时可以提升吞吐量。但也有不降低延时而提升吞吐量的情况,例如通过增加线程数。
关键观点3: 何时重点优化延时和吞吐量
在大规模系统的架构设计中,如果关注单用户体验则重点优化延时,如果关注能同时服务的用户数量则重点优化吞吐量。
关键观点4: 补充阅读材料的内容
补充阅读材料分为几章详细讲述了延时、吞吐量、二者关系,以及Web Server和Database的具体例子。文章进度和分享形式等也做了简要说明。
正文
有朋友问我说,架构优化时,什么时候要重点优化延时,什么时候要重点优化吞吐量?延时(Latency)与吞吐量(Throughput)是架构设计中非常重要,又非常容易搞混的两个指标。返回一个HTTP请求的时间是200毫秒,我们说请求的延时是200毫秒。生一个孩子的时间是10个月,我们说生孩子延时是10个月。一个请求的处理时间是200毫秒,单线程每秒钟可以处理5个请求,我们就说其的吞吐量是每秒5次。10个月能生一个孩子,我们就说生孩子的吞吐量是每10月1个。例如:200毫秒处理一个请求,优化为100毫秒处理一个请求,吞吐量就由5提升为10了。例如:单线程200毫秒处理一个请求,线程数增加到10,吞吐量就由5提升为50了。有时候,延时是很难降低,此时不能靠降低延时增加吞吐量。回到开篇的问题,架构优化时,什么时候要重点优化延时,什么时候要重点优化吞吐量?延时,延时更多是性能(performance)指标,关乎单用户体验。吞吐量,吞吐量是扩展性(scalability)指标,关乎同时能服务多少客户。系统的性能,是有天花板的,延时不能无限优化,不可能降到0。系统的扩展性,理论上是无限的,架构合理的话,吞吐量可以无限提升,能同时为无限多的用户同时服务。https://cs.fyi/guide/latency-vs-throughput后续我将以短视频+图文+直播+星球社群的形式,系统性的分享架构设计中的100个相关知识点,欢迎感兴趣的童鞋关注。
短视频的进度会快一些,码字有点麻烦,进度会慢一些,大伙静候。回归本心,希望为社区贡献自己的一小点力量。
平台的策略,专业内容不推流,大家多帮忙标星,以及点赞,转发,在看三连。感谢。