首页 > 解决方案 > 如何调试 Django 网站的长时间等待

问题描述

我有一个 Django 网站,我想改进它的响应时间。当我点击我网站上的站内链接时,结果要么是立即加载下一页,要么是在页面加载前等待 20-30 秒。我发现此行为中没有可重现的模式来帮助我确定修复程序。我意识到可能出现这种情况的原因有很多,并且需要有关我的特定配置的更多信息才能获得该领域的特定帮助。

但是,我希望其他人可以就我应该调查的一般领域提供与以下观察一致的建议,而不是转储配置信息页面并寻求具体建议:

调试工具栏显示总 CPU 时间和 SQL 查询时间在合理范围内(< 1 秒),但总浏览器请求时间为 22 秒(见图)。为什么这些值会如此不同?什么可能会导致几秒钟的请求时间不属于 CPU 时间?

在此处输入图像描述


更新1:修改gunicorn中的--access-logfile标志后,我能够从Django看到更详细的日志(如此处所述:http ://docs.gunicorn.org/en/stable/settings.html#logging ) . 这向我表明,在发生延迟的情况下,Django 直到 gunicorn 工作人员重新启动(大约需要 30 秒)才收到请求:

web_1 | 2019-07-23 15:33:06 +0000 [关键] 工作人员超时 (pid:9)
web_1 | [2019-07-23 11:33:06 -0400] [9] [INFO] 工人退出(pid:9)
web_1 | [2019-07-23 15:33:06 +0000] [10] [INFO] 使用 pid 引导工作人员:10

现在我只需要找出我的 gunicorn 工人出现故障的原因。


更新 2:我向 gunicorn 添加了 -w 4 标志(以前未指定此标志),问题似乎已经消失。我会继续测试,看看这是否是一个长期的解决方案。

标签: djangoperformancegunicorndjango-debug-toolbar

解决方案


好的,这是我找到的答案:

Debug 工具栏的 CPU 时间只反映了 Django 代码所用的时间。总请求时间比 CPU 时间长得多的事实反映了其他服务器端非 Django 代码组合所花费的时间。因此,修复不在 django 中,而是在服务器设置的其余部分之外。典型 django 部署的常见嫌疑人是 Django 本身前面的所有内容(例如 ngix、gunicorn 等)。

了解更多关于 gunicorn 标志(特别是 --access-logfile)的信息使我能够看到由 gunicorn 工作者产生的错误消息,这些错误消息反复(但不可重现)超时。虽然仍然不知道为什么会发生超时,但将工作人员从 1 个更改为 4 个(使用 -w 4 标志)已经解决了 30 秒页面加载延迟的原始问题。


推荐阅读