Django -使用templatetags渲染许多模板的速度非常慢
比方说，我有一个带有图片库的页面。每个缩略图都有一张照片、国家、作者等。我使用模板标签(加载指定的模板)来呈现这些项/小部件--这是因为DRY (我在页面上的不同位置分别使用这些项/小部件)。
而且速度非常慢。
我已经使用django-debug-toolbar执行了一些分析：
SQL Queries: default 84.81 ms (147 queries)但是：
Total CPU time: 5768.360 msec等待的时间太长了。
经过分析，发现主要的罪魁祸首是模板引擎。
例如，当我想要显示150张照片时，有600个相关的项目/小部件正在通过模板呈现。这意味着600次或更多的I/O操作。将这些小部件移动到主模板解决了这个问题，但不能保持干燥。
所以我的问题是如何避免这样的行为？是干而慢，还是不干而快？我宁可又干又快...
回答 6
Stack Overflow用户
发布于 2012-02-09 05:05:06
经过几个小时的分析和搜索。
谢谢您的帮助，但在这种情况下，我认为到目前为止最好的解决方案是使用Template fragment caching
我尝试了一下，获得了70-80%的速度性能！
{% load cache %}
{% cache 3600 mywidget_id %}
.. rendered mywidget is cached ..
{% endcache %}Stack Overflow用户
发布于 2012-02-08 03:46:36
您可能想尝试caching template loader，django.template.loaders.cached.Loader -它肯定会减少所需的IO量。
编辑要添加，您需要小心地假设，因为大部分时间都花在模板呈现阶段，所以查询计数不是罪魁祸首。不要忘记查询集是惰性的，除非您专门在视图中对它们进行切片或迭代，否则只有在加载模板时才会计算它们。我想说，通过很好地使用select_related和其他技术来减少查询数量应该会有很大的帮助。
Stack Overflow用户
发布于 2012-02-08 06:48:01
我假设，由于您使用的是调试工具栏，所以在开发过程中会得到这些数字。然而，正因为如此，这些都不是“真实”的数字。
内置的Django服务器很适合开发，但它有许多缺点，使得它比真正的The服务器慢得多。首先，它是单线程的，所以这意味着没有并行请求。这也意味着IO操作是离散的。其次，它的任务不仅仅是服务于Django的请求，还包括静态资源。
总而言之，如果你想真实地分析你的站点的页面加载时间，你需要在本地安装一个真正的‘ll服务器。基本上可以像在生产环境中一样设置它。我敢打赌，请求次数会好得多。
https://stackoverflow.com/questions/9182707
复制相似问题
腾讯云开发者
