延迟/吞吐量权衡:为什么快速服务缓慢,反之亦然

主要观点:作者开始阅读关于 DevOps 的书籍《Site Reliability Engineering》,其中关于低延迟用户和离线分析用户对系统请求队列需求的观点让其想到 ElasticSearch 管理的痛苦经历,进而探讨从排队角度看延迟、吞吐量和容量的关系。以给狗戴帽子的服务为例,说明同时满足低延迟和高吞吐量用户需求的集群是不可能的,应将集群分为“低延迟”和“高吞吐量”两类,让用户根据使用场景选择,后续文章将进一步探讨新集群的性能特征。
关键信息:

  • 书籍《Site Reliability Engineering》及相关链接。
  • 低延迟用户希望 Bigtable 请求队列几乎为空以立即处理请求,离线分析用户更关注系统吞吐量希望队列从不空。
  • 弹性搜索同时满足低延迟和高吞吐量需求会变糟糕。
  • 分为“低延迟”和“高吞吐量”集群,避免优先级拉锯。
    重要细节:
  • 以 200 个进程给狗戴帽子为例,理论容量为 500 顶/秒。
  • 现场戴帽用户关注延迟,批量戴帽用户关注吞吐量。
  • 满足现场用户需求需保证有处理器空闲,接近容量会使延迟剧增;批量用户希望队列满以获取接近容量的吞吐量。
  • 混合使用集群会导致双方需求都无法满足,分裂集群可避免优先级拉锯,后续文章将探讨新集群性能特征。
阅读 10
0 条评论