【问题标题】:Understanding benchmark of a Django view了解 Django 视图的基准
【发布时间】:2016-04-06 15:01:24
【问题描述】:

我正在尝试测量查询我的 Django 视图之一所需的时间。它基本上是使用不同的 LIMIT 子句(sqlite)进行 SELECT。下面是我得到的时序,先直接调用view函数,然后用urllib作为GET请求调用。

LIMIT  view(s.)  request(s.)
25     4.5       12.6
100    1.6       2.1
400    3.5       3.3
800    4.4       4.7
1600   7.6       8.4
...

为什么第一次时间这么长?是否有一些明显的原因,比如我无法禁用的缓存,或者数据库访问固有的?

我没有使用cache_page,我尝试完全禁用缓存,遵循我在网上找到的一些建议:

settings.CACHE_BACKEND = 'dummy:///'
settings.CACHES = {'default': {'BACKEND': 'django.core.cache.backends.dummy.DummyCache',}}

如果我不重新启动服务器并再次运行测试,12s(第一次请求调用)按预期变为 1s,但 4.5s(第一次查看调用)保持不变。

【问题讨论】:

标签: django caching benchmarking


【解决方案1】:

除了 Django 的请求缓存之外,还有数据库查询缓存、读取 sqlite 文件时的文件系统缓存等。但是,我不确定禁用缓存会完成什么。它们是现实世界请求-响应周期的一部分。

如果你想知道你的数据库查询效率,直接在数据库控制台(./manage.py dbshell)运行实际的SQL查询,使用EXPLAIN(在MySQLPostgresq,不确定sqlite )。这为您提供了数据库操作的详细列表以及每个步骤使用了多少资源。所以你可以从那里优化。

【讨论】:

  • 谢谢。我需要知道最坏情况的时间,例如用户第一次连接到应用程序时会发生什么(并设置适当的服务器超时)。查询本身需要 0.01 秒。执行,但将生成的 QuerySet 放入列表中需要几秒钟...谢谢 Python。如何禁用数据库查询缓存,以确保它来自其他地方?
  • 它很可能是数据库查询缓存,因为在我看来,我正在多次评估相同的 QuerySet。
  • 看来sqlite真的有缓存,大小用PRAGMA cache_size=xy,see this answer调整。如果您的结果数据很容易缓存,您可能会在应用程序启动时加载它,所以您在第一次请求时已经有了缓存?
  • @muraveill 将其放入QuerySet 需要很长时间,因为 django 将为数据库中的每条记录生成对象。检查QuerySetvaluesvalues_list 方法并尽可能使用它们,这将产生巨大的影响。
  • 使用values_list 大约快 2 倍。奇怪的是 sqlite3 游标 fetchall 也返回元组,但比 values_list 快 2 倍。之后我将它们映射到命名元组(几乎没有性能损失)。
猜你喜欢
  • 2015-04-30
  • 1970-01-01
  • 2013-12-24
  • 2013-04-15
  • 2014-01-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-02-16
相关资源
最近更新 更多