vlambda博客
学习文章列表

统计查询数量:Django中的基本性能测试

我们经常会读到有关测试技术(如TDD)和如何测试应用程序业务逻辑的文章。但是测试应用程序的性能是一个完全不同的问题。你有许多方法可以做到这一点,但是一种常见的方法是设置一个环境,你可以在这个环境中对你的应用程序执行DDoS攻击并观察它的表现。这是一个令人兴奋的话题,但我并不想在这篇博文中谈论它。今天我想介绍一种更简单的测试,你可以使用默认的Django单元测试设置来执行它:测试你的应用程序访问数据库的次数。


这是一件很容易测试的事情,而且它是在很早就会影响应用程序性能的事情之一。这也是我在某些应用程序开始运行缓慢时调查的第一件事情。好消息是,在开始编写这种测试时,你只需要知道一件事:assertNumQueries方法,它使用起来非常简单,这里是一个例子:

统计查询数量:Django中的基本性能测试


上面的代码断言:在"trucks:list_trucks"视图期间,应用程序将只会访问数据库6次。但是还有一点需要注意,在运行此断言之前,我们首先创建一个新的Truck对象,然后我们再断言在该视图的trucks_list上下文数据中有一个对象。在这种测试中,这是一件非常重要的事情,因为它可以确保你没有针对空数据集进行测试。仅仅创建Truck实例还不够,理解这一点是很重要的;你需要检查它是否包含在上下文中。你可能会对该卡车列表数据进行筛选,因此你的Truck实例可能不会被包括在结果中。


通过以上所做的,我们已经取得了显著的进步,但是还有一个重要的步骤是人们经常忘记的。如果我们想让视图进行伸缩,我们需要确保它的性能不会随着它返回的项的数量的增长而下降。毕竟,我们仍然有一个性能问题,如果我们访问数据库6次来获取一个项目的话,但如果我们有100个项目,我们就需要访问数据库106次。我们想要一个固定的数据库访问次数,不论我们正在返回的项的数量是多少。幸运的是,这个问题的解决方案也很简单,我们需要向数据库添加一个(或几个)条目,并再次统计访问次数。下面是该测试的最终版本:

统计查询数量:Django中的基本性能测试


注意,我们再次检查了上下文中返回的项的数量,但是在第二次运行中,我们得到了2个 truck。这里的原因和第一次是一样的。


在添加数据时,确保数据库访问次数不变要比拥有一个低的总访问次数更重要。


最后一件要做的事是确保你的数据尽可能是充足的。这意味着你还需要创建相关的数据,以便在处理视图时使用。如果你不这样做,则存在这样一个风险,你的生产应用程序访问数据库的次数比你的测试预期的次数要多(尽管它可能通过了测试)。在我们的示例中,我们需要为我们的TruckDriver创建一个同伴TruckDriver。


如果在执行上述操作之后,数据库访问次数不再保持不变,请进一步了解select_related和prefetch_related方法。


以上就是今天的全部内容,希望从现在开始,你可以在你的应用程序的早期检查数据库查询的数量。执行这项检查不会占用你太多的时间,而且当你的应用程序的用户数量开始增长时,它将会避免很多麻烦。


英文原文:https://www.vinta.com.br/blog/2020/counting-queries-basic-performance-testing-in-django/ 
译者:一瞬