在我的网站中，主页面（用户花费大部分时间）有大约140个查询（其中70个来自django-avatar模块 - 必须查看我是否可以找到替代方案有一天）。但是加载需要5秒钟（指标来自django-toolbar）。
我可以将查询数量增加到170，并减少加载到2.5秒（！）所需的时间。
为此，我必须简化使用annotate()的复杂查询，并通过迭代较小的查询来创建字典。我注意到虽然查询数量增加了，但是django更喜欢它，因为我通过删除注释来从复杂查询中删除负载。
我该怎么办？
PS：除MySql外，我还使用memcached
答案 0 :(得分：2)
首先，django-debug-toolbar提供主观性能测量，以便快速检查自己。如果你发现你的查询数量激增或者请求突然比以前花了更长的时间，那么你知道你需要深入了解并查看是否可以对其进行优化。但是， 不适合广义化＃34;我的网站响应速度如何？＃34;型式试验; django-debug-toolbar本身引入了许多低效率来为您提供数据。在禁用工具栏的情况下，您的代码将不可避免地执行更多而不是启用。如果你真的想要衡量你的网站，你需要使用一个分析后端在最佳条件下努力打击你的网站，并给你关于瓶颈发生的统计数据。
也就是说，您获得的时间统计数据不仅仅是查询依赖;它们还依赖于文件I / O，模板渲染等。如果您在开发中使用memcached，那么请求之间不可避免地会发生一些缓存，即使它只是缓存的模板。无需重新解析模板并创建响应对象需要花费大量时间来处理请求。因此，看起来170个查询可能更快，但这可能只是因为已经有一些缓存。如果关闭缓存，则时间可能会显着增加。如果您正在开发和优化查询负载，则应通过将缓存设置为DummyCache来完全禁用缓存。
最后，在开发过程中，转移请求的实际时间不是问题，因为它是本地到本地的，这几乎是即时的。在实际场景中，客户端需要花费数百毫秒的时间向您的服务器发送请求。如果您的数据库服务器与您的Web服务器不在同一台服务器上，则需要时间从Web应用程序向数据库发送来回请求，最后需要时间将响应发送回客户端。实际的传输时间通常会在实践中产生比查询时间更多的瓶颈，因此通常更少，更复杂的查询总是优于更多的小查询。
基本上，在开发过程中测试这些东西的变量太多了。像django-debug-toolbar这样的东西是一个很好的指南，但它并不全面，而且不是万无一失的。把你的代码放在类似生产的机器上并且努力工作 - 这是确定的唯一方法。