Heroku上Django应用请求排队性能问题排查求助

1. 先明确Request Queuing的本质 #

在Heroku环境下，这个指标指的是请求到达Heroku路由器后，等待被你的web dyno处理的时间——本质是可用处理能力跟不上请求量，但原因不一定是单纯的水平扩容问题，得拆解排查：

2. 最常见的触发原因 #

• Dyno资源饱和
  • 并发连接数超限：每个web dyno的并发处理能力由你的WSGI服务器（gunicorn/uwsgi）配置决定，比如gunicorn的worker数+线程数设置过低，导致单个dyno扛不住流量；或者所有dyno的总并发数低于峰值请求量。
  • CPU/内存耗尽：如果dyno的CPU持续跑满（>90%）或内存接近上限（触发swap），会导致worker处理请求的速度变慢，间接让新请求排队。哪怕Django业务逻辑本身没问题，比如依赖的数据库查询慢、第三方API同步调用阻塞，都会占用worker导致排队。
• WSGI服务器配置不合理
  比如gunicorn的worker数没按Heroku推荐设置：workers = (2 * CPU核心数) + 1（标准dyno是2核，建议设5个worker），或者线程数过少，导致单个dyno的处理潜力没发挥出来。
• 突发流量或路由限流
  短时间内流量暴增（比如活动、爬虫）超过Heroku路由器的临时阈值，会触发排队；日志里如果出现H12（请求超时）、H28（连接异常关闭）错误，大概率是这个情况。

3. 是否属于水平扩容问题？ #

不一定：

• 如果所有dyno的并发连接数、CPU/内存都接近上限，且WSGI配置已经合理，那就是水平扩容的问题——直接增加dyno数量就能缓解。
• 如果单个dyno的资源利用率很低（比如CPU只有30%，但worker数设成1），那先优化单dyno的配置，再考虑扩容更高效。

4. 验证排查步骤 #

• 查看Heroku的Metrics面板：重点看dyno并发连接数、CPU使用率、内存使用率，峰值时这些指标是否触顶。
• 实时查看日志：执行heroku logs --tail，关注日志里的queue_time字段，持续超过100ms说明排队严重；同时看有没有H12这类路由器级别的错误。
• 检查WSGI服务器日志：确认worker是否被长时间占用（比如某个请求耗时超过5秒），排查是否有隐性的阻塞点（比如未优化的ORM查询、同步第三方调用）。

内容的提问来源于stack exchange，提问作者Martijn van den Kerkhof