docker - 通过请求调用嵌套的 FastAPI REST API 会降低性能吗？
问题描述
容器 1 中的 API 1 --> 容器 2 中的 API 2
我在一个 docker 容器中有一个简单的 FastAPI REST API (API 1) 调用另一个 docker 容器中的另一个简单的 FastAPI REST API (API 2)。调用是通过请求包进行的。
当我对 API 2 (ab -n 10000 -c 500 http://[url of API 2]) 执行 Apache Benchmark 测试时，每秒的 (RPS) 请求约为 4600。但是，当我执行相同的 apache 基准测试时在 API 1（ab -n 10000 -c 500 http://[API 1 的 URL]）上，尽管 API 1 只是对 API2 的简单 requests.post 调用，但 RPS 下降到 1350 左右，没有任何处理逻辑。我不明白为什么嵌套调用会如此大幅度地降低 RPS
容器 0 中的 API 0 --> 容器 1 中的 API 1 --> 容器 2 中的 API 2
为了进一步证实我的观察，我在另一个 docker 容器中创建了另一个 FastAPI REST API 0，其中包含对 API 1 的简单 request.post 调用。apache 基准测试（ab -n 10000 -c 500 http://[url of API 0]) 进一步放缓至 RPS 530
我可以知道原因吗？我认为对 FastAPI REST API 的 http 请求调用不应该在一系列嵌套调用中增加那么多开销
在我的微服务分布式应用程序中，我在不同的容器中托管了多个微服务，因此对来自客户端浏览器的请求的某些处理可能会导致微服务之间的嵌套调用（例如，客户端浏览器调用 A、A 调用 B、B 调用 C）
解决方案
绝对而言，如果您的容器堆栈每秒处理 530 个请求，则每个请求需要 1.9 毫秒。总体来说还是不错的。（我在日常工作中担心的性能问题是需要几分钟才能完成的单个 HTTP 请求。）我不会担心调整它。
将其分解为延迟（每个请求的时间）而不是吞吐量（每单位时间的请求数）可能更有趣。Apachebench 可能会输出中位数和 99% 的延迟。不过，只看平均值：
| 小路 | 吞吐量 | 平均延迟 |
|---|---|---|
| api2 | 4600 个请求/秒 | 217 微秒 |
| api1 → api2 | 1350 个请求/秒 | 740 微秒 |
| api0 → api1 → api2 | 530 个请求/秒 | 1886 微秒 |
217 µs 相当快；为额外的 HTTP 跃点添加 0.5-1.0 毫秒对我来说似乎是合理的。请记住，Python 是一种解释型语言，因此如果您以微秒为单位，此设置可能会比 Go 之类的编译型语言慢；而且您的“真实”应用程序可能会涉及数据库，并且在大多数情况下，SQL 请求会立即使这些数字相形见绌。如果数据库往返需要至少 100 毫秒，那么为 HTTP 代理跃点增加 1 毫秒基本上是免费的。
在您描述的微服务环境中，具有一系列跨服务调用是非常典型的。我建议单独调整每个服务：如果服务 B 调用服务 C 两次，并且服务 C 需要 500 毫秒来处理请求，那么整个堆栈将需要 > 1 秒才能运行，但单独分析服务 C 将有望指向问题。根据我的经验，您最需要关注的是数据库设置。抽象地说，网络跳数越少越好，但您在此处显示的数字表明，添加或删除代理不会对最终性能产生很大影响。