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

《架构师之路：架构设计中的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集：究竟怎么做架构设计？

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

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