Uvicorn+FastAPI多Worker请求负载不均问题求助

复现代码 #

import time
from fastapi import FastAPI
from concurrent.futures import ThreadPoolExecutor
import asyncio
import os
import random

app = FastAPI()
executor = ThreadPoolExecutor(max_workers=1)
loop = asyncio.get_event_loop()

class SomeClass():
    def task(self):
        random_time = random.randint(2000, 3000) / 1000
        time.sleep(random_time)
        return f"process id: {os.getpid()}"

@app.get("/test")
async def test():
    instance = SomeClass()
    result = await loop.run_in_executor(executor, instance.task)
    print(result)
    return result

测试步骤 #

• 启动服务：uvicorn --workers 2 main:app
• 发送20个并行请求：for i in {1..20}; do curl http://127.0.0.1:8000/test & done

预期结果 #

• 约10个请求由第一个Worker处理
• 约10个请求由第二个Worker处理
• 总耗时约25秒

实际结果 #

• 14个请求由第一个Worker处理
• 6个请求由第二个Worker处理
• 总耗时约35秒

输出日志 #

process id: 56017
process id: 56016
process id: 56017
process id: 56016
process id: 56017
process id: 56016
process id: 56017
process id: 56016
process id: 56017
process id: 56016
process id: 56017
process id: 56017
process id: 56017
process id: 56017
process id: 56017
process id: 56017
process id: 56017
process id: 56017
process id: 56017

疑问 #

已知time.sleep会阻塞事件循环，但已经将阻塞函数放到asyncio线程池执行，为何仍然出现负载不均、耗时超出预期的问题？

问题原因 #

1. 操作系统层面的连接调度逻辑：Uvicorn默认依赖操作系统的SO_REUSEPORT特性实现多Worker负载均衡，但这一机制并非严格轮询。当大量请求同时发起时，系统可能会将多个连接分配给同一个Worker——尤其是当Worker处理请求的速度存在差异（比如你的任务有随机sleep时长）时，这种不均衡会被放大。
2. 单线程线程池的瓶颈：每个Worker进程只配置了1个线程的ThreadPoolExecutor，意味着单个Worker同一时间只能处理1个阻塞任务。当第一个Worker被分配更多请求后，后续请求会在该Worker的事件循环队列中排队，总耗时由该Worker的任务总量决定（14个任务×平均2.5秒=35秒），而第二个Worker的任务量少，耗时更短，整体总耗时被最慢的Worker拉满。

优化建议 #

• 调整线程池大小：增大ThreadPoolExecutor的max_workers值，比如设置为os.cpu_count()或更高，让单个Worker能同时处理多个阻塞任务，减少请求排队时间。
• 引入反向代理：如果需要严格的负载均衡，可在Uvicorn前部署Nginx等反向代理，通过配置round_robin等轮询策略，确保请求均匀分配到各个Worker。
• 调整Worker连接数：增大Uvicorn的--worker-connections参数，提升单个Worker能处理的并发连接数，降低连接排队概率。

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