运维 计算阻塞 IO web server 的最大吞吐量

hjiangwen · 2021年06月24日 · 最后由 yfractal 回复于 2021年06月28日 · 409 次阅读

计算

如果我们用 RPM(每分钟请求量)来衡量吞吐量,我们可以用这个公式来计算阻塞 IO web server 的最大吞吐量:

  • 线程的 RPM = 60s / 平均响应时间
  • 一个容器的 RPM = 进程数 * 线程数 * 线程的 RPM
  • 所有容器的 RPM = 一个容器的 RPM * 容器数量

假设我们 web server 的平均响应时间是 150ms,一个容器里有 2 个进程,每个进程有 5 个线程,那么

  • 线程的 RPM = 60s / 150ms = 400
  • 一个容器的 RPM = 2 进程 * 5 线程 * 400 = 4k
  • 如果我们运行 50 个容器,则吞吐量是 50 * 4k = 200k RPM
  • 如果我们运行 500 个,则吞吐量为 500 * 4k = 2m RPM

慢 API 如何影响吞吐量

假设我们依赖的外部服务不可用,导致请求超时,而且我们没设置请求超时时间,惨。导致关键 API 变得很慢,外部服务的响应时间甚至达到了 30-60s。 这时假设平均响应时间从 150ms 变为 10s,那么

  • 线程的 RPM = 60s / 10s = 6
  • 一个容器的 RPM = 2 进程 * 5 线程 * 6 = 60
  • 所有容器的 RPM = 60 * 500 个 = 30k

最终这个慢 API 导致我们的 RPM 从 2m 变成 30k,接着用户体验会变得很糟糕,第 30000 个之后的请求都会被放到请求队列中,请求积累的越来越多,大部分请求还在排队时,就已经超时了。用户在 app 只能看到加载动画或者错误。

这时假设平均响应时间从 150ms 变为 15s,那么

线程的 RPM = 60s / 10s = 6。不是应该 RPM = 60 / 15s = 4 ?

lanzhiheng 回复

多谢提醒,已改

这个其实可以引出来很多东西。

一个是超过这个最大吞吐,系统的行为是什么,怎么解决。

工业的解决方案是加限流。这个是试用简单的场景。再好一点是用背压。网飞有一个 lib,机制类似 tcp 拥塞控制。facebook 的 memchahe 也用了类似的机制。

这个 https://pdos.csail.mit.edu/6.S081/2020/readings/mogul96usenix.pdf 讲了一个类似的事情,主要是解决方案。

Congestion Avoidance and Control 这个里面讲了背后原因,

需要 登录 后方可回复, 如果你还没有账号请 注册新账号