通过请求调用嵌套的 FastAPI REST API 会降低性能吗？答案

【问题标题】：Will nested FastAPI REST API call via requests slow down the performance?通过请求调用嵌套的 FastAPI REST API 会降低性能吗？
【发布时间】：2021-09-30 07:53:26
【问题描述】：

容器 1 中的 API 1 --> 容器 2 中的 API 2

我在一个 docker 容器中有一个简单的 FastAPI REST API (API 1) 调用另一个 docker 容器中的另一个简单的 FastAPI REST API (API 2)。调用是通过 requests 包进行的。

当我对 API 2 (ab -n 10000 -c 500 http://[url of API 2]) 执行 Apache Benchmark 测试时，每秒的 (RPS) 请求约为 4600。但是，当我执行API 1 上的相同 apache 基准测试（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://[ API 0]) 的 url 进一步减慢到 RPS 530

我可以知道原因吗？我认为对 FastAPI REST API 的 http 请求调用不应该在一系列嵌套调用中增加那么多开销

在我的微服务分布式应用程序中，我有多个微服务托管在不同的容器中，因此来自客户端浏览器的某些请求处理可能会导致微服务之间的嵌套调用（例如，客户端浏览器调用 A、A 调用 B、B 调用 C）

【问题讨论】：

附加信息——每个容器（Alpine）中的 FastAPI REST API 由运行 uvicorn.workers.UvicornWorker 工作人员的 Gunicorn 提供支持。我在不同的 docker 容器中托管 REST API 的原因是为了模仿 K8s 中的 pod。最终我想在 K8s 上运行它

标签： docker python-requests nested benchmarking fastapi

【解决方案1】：

绝对而言，如果您的容器堆栈每秒处理 530 个请求，则每个请求需要 1.9 毫秒。总体来说还是不错的。（我在日常工作中担心的性能问题是需要分钟才能完成的单个 HTTP 请求。）我不会担心调整这个。

根据延迟（每个请求的时间）而不是吞吐量（每单位时间的请求数）来分解它可能更有趣。 Apachebench 可能会输出中位数和 99% 的延迟。不过，只看平均值：

Path	Throughput	Average Latency
api2	4600 req/s	217 µs
api1 → api2	1350 req/s	740 µs
api0 → api1 → api2	530 req/s	1886 µs

217 µs 相当快；为额外的 HTTP 跃点添加 0.5-1.0 毫秒对我来说似乎是合理的。请记住，Python 是一种解释型语言，因此如果您以微秒为单位，此设置可能会比 Go 之类的编译型语言慢；而且您的“真实”应用程序可能会涉及数据库，并且在大多数情况下，SQL 请求会立即使这些数字相形见绌。如果数据库往返需要至少 100 毫秒，那么为 HTTP 代理跃点增加 1 毫秒基本上是免费的。

在您描述的微服务环境中，具有一系列跨服务调用是非常典型的。我建议单独调整每个服务：如果服务 B 调用服务 C 两次，并且服务 C 需要 500 毫秒来处理请求，那么整个堆栈将需要 > 1 秒才能运行，但单独分析服务 C 将有望指向问题。根据我的经验，您最需要关注的是数据库设置。抽象地说，网络跃点越少“越好”，但您在此处显示的数字表明，添加或删除代理不会对最终性能产生很大影响。

【讨论】：