计算

如果我们用 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 只能看到加载动画或者错误。