通过requests嵌套调用FastAPI接口为何会大幅降低服务性能？

核心原因 #

• 同步IO阻塞导致资源利用率极低：你使用的requests库是纯同步的HTTP客户端，搭配FastAPI的同步路径函数时，每个请求在等待下游API返回的过程中，会全程占用所在的worker线程，无法处理其他请求。多层嵌套调用时，每一层的阻塞都会叠加，直接拉低整体并发处理能力，这是RPS大幅下降的最主要原因。
• 多层网络与连接开销叠加：每增加一层API调用，就会多出一整套完整的HTTP请求-响应流程，包含TCP连接建立（如果未复用长连接）、HTTP报文解析/序列化、docker网桥转发、内核网络栈处理等开销。如果没有开启连接复用，每次请求新增的三次握手、四次挥手开销会在高并发场景下被指数级放大。
• 压测工具与服务配置缺陷：Apache Benchmark（ab）默认使用HTTP/1.0协议，不开启Keep-Alive，每次请求都会新建TCP连接，本身就会放大嵌套调用的性能损耗；如果FastAPI启动时worker数配置过少，也会进一步限制并发处理能力。
• 序列化/反序列化开销叠加：每一层API都需要对请求体、响应体做一次解析和序列化操作，多层叠加后在高并发场景下会消耗大量CPU资源，进一步拖慢处理速度。

优化方案 #

• 替换同步HTTP客户端：将requests替换为异步HTTP客户端httpx.AsyncClient，搭配FastAPI的异步路径函数使用，IO等待时worker可以切换处理其他请求，大幅提升资源利用率和并发能力。
• 启用长连接复用：HTTP客户端使用连接池配置，复用已有TCP连接，避免重复的连接建立/销毁开销。同步场景下可以使用requests.Session复用连接，异步场景下httpx默认自带连接池，按需调整最大连接数即可。
• 调整服务与压测配置：
  • 使用uvicorn启动FastAPI时，将worker数调整为CPU核心数的2~4倍，同时调整keepalive_timeout、backlog等参数适配高并发场景
  • 压测工具替换为wrk或hey，默认支持HTTP/1.1与Keep-Alive，测试结果更贴合实际生产场景
• 降低网络开销：同机部署的容器可以使用Unix域套接字替代TCP通信，或开启docker的host网络模式，减少网桥转发的额外开销。

内容的提问来源于stack exchange，提问作者Happy-Toro