如何弄清楚为什么渲染base.html在生产中非常慢(在Heroku上)

时间:2013-10-14 20:04:06

标签: python django heroku

我已经在Heroku上运行了几个月没有问题的Django应用程序。无处不在,它变得极其缓慢/无响应,并且占用了大量的内存。

New Relic密码告诉我,98%的加载时间是“应用程序代码(在Render / base.html中)”,但没有告诉我任何其他内容。据我所知,我们没有改变base.html中会导致其行为不同的任何内容。

其他人遇到过这个问题?我如何排除故障/到达底部?

谢谢!

更新 - 我无法再将更改推送到Heroku。它在“清理...”或“收集静态文件”之前停止超时(如果超过15分钟,Heroku会杀死编译)。

1 个答案:

答案 0 :(得分:0)

虽然我不确定我是否完全理解问题的根本原因,但我解决了症状,我想在此发帖,以便其他遇到相同问题的人需要帮助。

同时发生了两个不同的问题。

首先,我在每个dyno上运行了太多的gunicorn工作人员。他们吞噬了很多内存(原因我还不知道--Heroku有点像黑盒子)并放慢了一切。改变我的Procfile,这样每个dyno只有一个gunicorn工作者解决了这个问题,至少目前是这样。

我的Procfile现在看起来像:

web: newrelic-admin run-program gunicorn myapp.wsgi --workers=1 --timeout=25

其次,结果我的s3桶充满了> 100k JavaScripts我的应用程序自动生成(我正在使用一个名为django_compressor的工具),当Heroku在部署期间运行collectstatic时,它试图检查s3上是否有任何更改,要求它迭代超过100k文件。每当我尝试将新部署推送到Heroku时,都会导致超时。

django_compressor造成了这种情况,因为我在base.html中意外地在{%compress js%}标记内包含了一个用于其他JavaScripts的块。

不要这样做:

{% compress js %}
<script src="..." />
<script src="..." />
{% block additionaljs %}{% endblock %} <--- BAD -- should be outside of the {% compress %} tags
{% endcompress %}