开发随笔——Django启动缓慢且接收请求存在高延迟

本文链接：https://blog.youkuaiyun.com/qq_41008078/article/details/145842308

开发随笔——Django启动缓慢且接收请求时间长

在某次开发时，我突然发现在使用python manage.py runserver启动Django项目时，多提示了一条[2025-02-25 02:47:26,592: INFO] Watching for file changes with StatReloader

并且在输出System check identified no issues (0 silenced).后陷入了长时间的停滞，约莫20秒左右后，Django项目正常启动。

但是此时无论是前端通过Nginx进行转发，或是我直接使用Postman对后端发送请求，都会停滞一段时间后后端才能接收到请求。但是如果直接在浏览器地址栏发送请求又能在一瞬间达到后端。

我的Django后端部署在localhost上，本不应该有延迟问题的，并且在我多次重启后问题依旧存在。

文章目录

开发随笔——Django启动缓慢且接收请求时间长

想直接看解决方法的直接拉到最后就行了，最后我也没怎么弄懂问题原因。

时间戳

我通过Postman发送了一条带有时间戳的请求，Django后端的消息显示为

[2025-02-25 03:06:02,070] "GET /api/ping?time=1740423941 HTTP/1.1" 200 41

在这里插入图片描述

此时产生了21秒的接收延迟，同时Postman的时间分析也显示

在这里插入图片描述

故可以发现出问题的部分在于，从请求发送到后端的时间上。

但奇怪的就偏偏是，如果我通过浏览器的地址栏直接发送请求，其又能几乎在瞬间接收到请求。

由于该问题是刚出现，因此我试图结合这几天进行过的操作进行倒退。

Django响应慢

我查询了相关Django响应慢的相关博客，大多都认为是Django查数据库这个动作耗费了大量的时间，而最近几日我虽然因为需要增加了几张表，但是显然还到不了延迟从0秒到20秒的可怕情况。

但为了排除这个可能性，我尝试了几种优化方式，但是都未能见到响应时间缩短，故而我暂时放弃了这个可能性。

StatReloader

再后来，我怀疑是否是Watching for file changes with StatReloader这条内容包含了什么信息，在stack overflow上，有人贴出了相关文档内容。

If you’re using Linux or MacOS and install both pywatchman and the Watchman service, kernel signals will be used to autoreload the server (rather than polling file modification timestamps each second). This offers better performance on large projects, reduced response time after code changes, more robust change detection, and a reduction in power usage.

(Runserver docs)

总的来说，这个提示似乎并不会影响到项目。

而在其他博客里有人提及

其实这个报错是Django有时可能有文件移动，或者是有其他文件上的删除等操作导致的，并不影响Django服务的正常运行，直接忽视就好了，如果觉得看着碍眼的话，可以尝试一下静态文件收集的指令

因此我尝试了一下python manage.py的相关操作，结果意外发现，不仅仅是在运行时访问出现了延迟问题，就连makemigrations都出现了意想不到的高延迟。

这时我才反应过来，有没有可能不是数据库处理变慢了，而是连接到数据库的过程变慢了

WSL配置

这是我一开始完全没想到的一个方向，但是排除了所有情况，也唯独这个了。

前一段因为需要使用WSL配置一个仅在Linux环境下运行的项目，并且需要连接公网以及Github和DockerHub，所以我直接修改了.wslconfig为以下内容

[experimental]
autoMemoryReclaim=gradual
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

这修改了WSL的网络模式，从而使得我不需要反复设置代理（之所以这么做是因为我在WSL中设置代理的情况下会经常出现连不上网的情况），而且这期间，我只在Windows中的后端发送了几个异步任务到任务队列上，这玩意一时间看不出来接收请求的情况。

当时异步任务也曾出现过请求缓慢的情况，但当时我以为是异步任务导致的所以没有在意，现在想来真的是害惨了自己。

回到正题，在移除了.wslconfig文件后，我重启了WSL，再次测试就恢复正常了。

[2025-02-25 03:15:20,120] "GET /api/ping?time=1740424520 HTTP/1.1" 200 41

在这里插入图片描述

回想原因，大抵是因为我的数据库通过Docker进行创建，而修改WSL网络配置的时候意外影响到了Docker所使用的网络内容，导致我在通过本地端口访问数据库时，受到了本地代理设置的影响，而通过浏览器访问时，却恰好因为会通过代理端口发送而保持了正常访问速度。