Django/Gunicorn请求延迟启动视图处理问题排查求助

我正在优化应用的请求响应时间，已经完成缓存实现、减少重复数据库调用等工作。但通过监控工具发现，部分请求需要耗时很久才开始处理视图，这给API请求设置稳定SLO带来了困难。我对Gunicorn Worker和线程的了解有限，但认为当前配置未达瓶颈（如无可用线程/Worker）。

环境配置 #

• Django = 3.2.15
• Django Rest Framework = 3.13.1
• Gunicorn = 20.0.4
• 数据库：基于RDS的PostgreSQL

Gunicorn启动命令 #

"gunicorn",
"--workers=4",
"--threads=8",
"--bind=0.0.0.0:8000",
"--worker-class=uvicorn.workers.UvicornWorker",
"webapp.asgi:application"

缓存配置 #

CACHE_MIDDLEWARE_ALIAS = 'default'
CACHE_MIDDLEWARE_SECONDS = 60
CACHE_MIDDLEWARE_KEY_PREFIX = ''

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": f"{REDIS_CONN_STRING}/0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
        }
    }
}

CACHEOPS_REDIS = f"{REDIS_CONN_STRING}/0"

CACHEOPS = {
    # 禁用用户/认证相关的缓存操作
    'auth.*': None,
    'users.*': None,
    'rest_framework.authtoken.models.token': None,

    '*.*': {'ops': (), 'timeout': 60},
}

基础设施信息 #

• 应用运行在ECS上，由2台c6g.xlarge实例（4核）做负载均衡
• Elasticache实例为cache.t4g.medium，平均内存占用400MB
• 监控截图：

1. 验证请求排队情况 #

先通过Gunicorn日志确认请求是否在排队：

• 开启日志并添加排队时间参数，修改启动命令的日志配置：

  "--access-logfile=-",
  "--access-logformat='%(h)s %(l)s %(u)s %(t)s \"%(r)s\" %(s)s %(b)s \"%(f)s\" \"%(a)s\" %(L)s'"
  

  其中%(L)s代表请求从进入Gunicorn到开始被Worker处理的耗时，若该值持续偏高，说明确实存在排队问题。

2. 调整Gunicorn Worker配置 #

你使用的UvicornWorker是异步Worker，Gunicorn的--threads参数对它无效——异步Worker靠事件循环处理并发，多线程反而会增加切换开销。针对4核的c6g.xlarge实例，建议调整配置：

• 移除--threads=8参数
• Worker数量设置为CPU核心数+1（即5个），或保持4个但去掉线程配置
• 可添加--worker-connections=1000（异步Worker并发连接数，可根据压测调整）

调整后的启动命令：

"gunicorn",
"--workers=5",
"--bind=0.0.0.0:8000",
"--worker-class=uvicorn.workers.UvicornWorker",
"--worker-connections=1000",
"webapp.asgi:application"

3. 修复CacheOps配置有效性 #

当前CacheOps配置中'*.*': {'ops': (), 'timeout': 60}未开启任何ORM层面的缓存操作（ops为空元组），仅依赖视图缓存中间件的话，ORM查询仍会直接访问数据库。建议修正配置，比如给非敏感模型开启查询缓存：

CACHEOPS = {
    'auth.*': None,
    'users.*': None,
    'rest_framework.authtoken.models.token': None,
    # 给其他模型开启查询类操作缓存
    '*.*': {'ops': ('fetch', 'get'), 'timeout': 60},
}

4. 基础设施瓶颈排查 #

• 检查ECS实例的CPU使用率、CPU credits消耗情况（c6g实例若credits耗尽会出现性能突降）
• 用redis-cli --latency测试Elasticache的响应延迟，若Redis延迟过高，会拖慢缓存查询环节
• 确认负载均衡的流量分配是否均匀，避免单台ECS实例过载

5. 排查应用内阻塞点 #

即使是异步Worker，若视图或中间件存在同步阻塞操作（如未缓存的ORM查询、同步第三方API调用），会阻塞事件循环导致请求排队。可使用py-spy做采样分析，或用django-debug-toolbar定位视图处理前的耗时环节（如认证、中间件逻辑）。

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