Django+Apache环境下首次请求TTFB延迟5秒问题排查求助

1. Gunicorn进程配置与预热 #

• 检查--workers --threads参数：如果worker数量太少，首次请求时worker进程可能刚启动，得完成Django应用的全量初始化（加载配置、注册app、初始化第三方库），直接拉高TTFB。试试调高worker数，或者加--preload参数让worker提前加载应用代码，避免首次请求时的初始化开销。
• 拉Gunicorn的启动日志和首次请求日志，看初始化阶段有没有阻塞操作，比如某个模块加载超时。

2. Django的首次请求初始化逻辑 #

• 排查各app的ready()方法：如果某个app的ready()里有耗时操作（比如远程API调用、大文件读取、全局对象初始化），debug模式下Django会提前加载，但Gunicorn的worker要等到首次请求才触发这些操作，直接导致延迟。可以给ready()加日志定位，或者把耗时操作改成懒加载（第一次用到再初始化）。
• 检查模块级别的代码：如果有模块在导入时就执行了耗时操作（比如数据库连接、第三方SDK初始化），Gunicorn的worker启动时没加载，首次请求才触发，拖慢TTFB。把这些操作移到函数内部，按需执行。

3. 系统层面的资源限制与连接问题 #

• 检查文件描述符限制：如果Gunicorn的worker进程能打开的文件数不够，首次请求时要申请资源，导致延迟。用ulimit -n查看当前限制，必要时调高。
• 排查内存状态：如果服务器内存不足，首次请求会触发swap交换，直接卡5秒。用free -h或top看内存使用情况。
• 检查TCP连接复用：连续请求快可能是复用了已建立的worker进程或连接，看看系统的TCP参数（比如net.ipv4.tcp_tw_reuse）是否开启，不过更可能是进程层面的复用问题。

4. 第三方依赖的初始化延迟 #

• 排查Django的第三方中间件/库：比如缓存后端（哪怕测试无DB页面，Redis等缓存库首次连接也要建立）、静态文件处理（比如whitenoise的初始化）、认证中间件等。这些库可能要等到首次请求才完成初始化，导致延迟。可以逐个禁用中间件测试，看TTFB是否改善。
• 确认Gunicorn的SSL会话缓存：虽然你排除了SSL，但如果用Gunicorn直接处理SSL，看看是否开启了会话缓存（--ssl-session-cache参数），避免首次请求的握手开销。

5. Gunicorn的worker类型调整 #

• 更换worker类型：默认的sync worker在处理首次请求时可能阻塞，试试用gevent或eventlet异步worker，启动命令改成gunicorn --worker-class=gevent mysite.wsgi，看延迟是否消失。
• 检查worker超时配置：如果--timeout设置过短，首次请求时worker被重启，导致重复初始化，适当调高超时时间。

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