Django认证完成到视图dispatch间的延迟问题排查求助

• 排查中间件链的后续逻辑
  django.contrib.auth.authenticate执行后，请求还会经过后续的中间件处理才会到达视图的setup方法。检查项目中所有自定义或第三方中间件，尤其是在AuthenticationMiddleware之后注册的中间件：

  • 逐个注释中间件，测试延迟是否消失，定位可疑中间件；
  • 在中间件的__call__方法前后添加时间戳日志，记录每个中间件的执行耗时。

• 检查Session处理流程
  认证完成后通常会伴随Session的读写操作，这部分可能成为延迟点：

  • 如果使用数据库Session，查看PostgreSQL慢查询日志，检查django_session表是否存在锁等待、索引缺失或慢读写；
  • 如果使用缓存Session（如Redis），检查缓存服务的连接池配置、响应延迟，是否存在超时或连接耗尽；
  • 临时切换为内存Session（SESSION_ENGINE = 'django.contrib.sessions.backends.cache'搭配本地内存缓存），验证延迟是否与Session后端相关。

• 追踪Graphene-Django的前置处理
  Graphene-Django的GraphQLView在进入setup/dispatch前有自身的前置逻辑：

  • 自定义继承GraphQLView，在setup方法执行前后添加时间戳日志，明确延迟是否发生在Graphene的内部前置流程中；
  • 检查Schema是否存在动态生成、懒加载逻辑，这类逻辑可能在首次请求或特定条件下触发耗时操作；
  • 查看Graphene-Django的权限校验逻辑，是否有自定义权限类在视图处理前执行了耗时操作。

• 排查Django信号的执行
  authenticate成功后会触发user_logged_in等信号，若信号接收器存在耗时操作，会导致这段延迟：

  • 临时禁用所有自定义信号接收器，测试延迟是否消失；
  • 检查信号接收器是否存在同步调用外部服务、数据库批量操作、未正确使用异步任务（如误用同步调用Celery任务而非delay）的情况。

• 验证Gunicorn的运行状态
  虽排除了worker耗尽，但仍需确认worker的运行状态：

  • 查看gunicorn日志，是否有worker重启、OOM杀死的记录；
  • 用ps aux检查worker进程状态，是否有进程处于D（不可中断睡眠）状态，排查是否存在IO阻塞；
  • 确认worker的线程/进程配置是否合理，是否存在锁竞争导致的阻塞。

• 系统层面资源排查
  服务器资源波动可能导致请求延迟：

  • 在延迟出现的时间段，查看服务器CPU、内存、磁盘IO、网络带宽的使用率，是否存在资源耗尽；
  • 检查是否有定时任务、备份脚本等在同一时间段运行，占用了系统资源；
  • 查看系统日志（/var/log/syslog或/var/log/messages），是否有硬件、网络相关的错误记录。

• 检查CSRF校验流程
  若为POST请求，认证后会执行CSRF校验：

  • 测试环境临时关闭CSRF校验（csrf_exempt装饰视图），验证延迟是否与CSRF处理相关；
  • 检查自定义CSRF后端的逻辑，是否存在缓存查询、数据库操作等耗时步骤。

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