FastAPI异步接口性能瓶颈咨询：每秒仅处理2-3请求

问题背景 #

我在FastAPI路由处理器中使用单例aiohttp.ClientSession()实例调用外部TTS服务，代码如下：

async def handler():
    log...
    async with client.post(
                f"{config.TTS_SERVER_ENDPOINT}/v2/models/{self.MODEL_NAME}/infer",
                json=request_payload,
            ) as response:
                response_data = await response.json()  # ✅ Get JSON response
    log...

压测后发现每秒仅能处理2-3请求，远低于预期，日志中"start"和"finish"数量远少于预期，且请求开始与结束的间隔从0.5秒逐渐增至5-6秒。当前服务部署在1核CPU、2G内存的Docker容器中，启动命令：

CMD ["uv", "run", "gunicorn", "-k", "uvicorn.workers.UvicornWorker", "-w", "4", "--threads", "16","--worker-connections", "2000", "-b", "0.0.0.0:8000","--preload", "src.main:app"]

可能的瓶颈点 #

1. 外部TTS服务性能限制 #

你的FastAPI服务大部分时间处于等待TTS服务响应的状态，这是最核心的瓶颈可能性。如果TTS服务本身处理单请求就需要0.5-6秒，且并发处理能力不足，那么FastAPI会被阻塞在等待响应环节，整体QPS自然上不去。建议单独压测TTS服务，确认它的单请求响应时间和最大可支撑QPS。

2. 资源与进程/线程配置不匹配 #

你用1核CPU却配置了4个Uvicorn Worker和16个线程，完全不合理。UvicornWorker是基于asyncio的异步Worker，本身为单线程模式，1核CPU下多Worker会频繁触发上下文切换，大幅增加调度开销，反而降低性能。异步服务在单核环境下通常只需要1-2个Worker即可，过多Worker只会拖慢整体速度。

3. aiohttp.ClientSession连接池限制 #

虽然使用了单例ClientSession，但它默认的连接池存在限制（默认connector的limit为100）。如果TTS服务响应慢，大量请求会占用连接池中的连接，后续请求需要等待连接释放，进而导致请求排队，间隔越来越长。可以调整连接池参数，示例如下：

client = aiohttp.ClientSession(connector=aiohttp.TCPConnector(limit=200, limit_per_host=200))

注意调整的前提是TTS服务能承受对应量级的并发连接。

4. Docker CPU资源不足 #

1核CPU的配置本身就很低，当多个Worker和线程同时运行时，CPU会成为严重瓶颈。异步服务虽擅长高并发，但如果CPU使用率接近100%，事件循环无法及时处理任务，必然导致请求延迟持续增加。可以用docker stats或容器内的top命令查看CPU使用率，确认是否存在资源耗尽的情况。

5. Gunicorn配置不合理 #

UvicornWorker是异步Worker，无需配置--threads参数——异步Worker的并发依赖事件循环实现，线程数设置会被忽略或造成不必要的资源浪费。另外--preload参数在多Worker场景下，会导致单例对象（如你的aiohttp.ClientSession）被多进程共享，虽然ClientSession线程安全，但多进程环境下fork出的实例可能引发连接池混乱或异常。

优化建议 #

• 调整Gunicorn配置：1核CPU下设置-w 1或-w 2，移除--threads 16参数，若使用多Worker则去掉--preload。
• 单独压测TTS服务，确认其性能是否能支撑预期并发量。
• 根据TTS服务的承载能力，适当调整aiohttp.ClientSession的连接池参数。
• 增加Docker的CPU资源至2核以上，再根据CPU负载调整Worker数量。

内容的提问来源于stack exchange，提问作者ddor254