Compréhension de l’évaluation du QuerySet¶

Pour éviter des problèmes de performance, il est important de comprendre :

• que les QuerySet sont différés.

• quand ils sont évalués.

• comment les données sont conservée en mémoire.

Compréhension des attributs mis en cache¶

Tout comme la mise en cache d’un QuerySet global, il y a mise en cache du résultat des attributs dans les objets de l’ORM. En général, les attributs qui ne sont pas exécutables seront mis en cache. Par exemple, à partir des modèles d’exemple du blog:

>>> entry = Entry.objects.get(id=1)
>>> entry.blog  # Blog object is retrieved at this point
>>> entry.blog  # cached version, no DB access

Mais généralement, les attributs exécutables provoquent des accès à la base de données à chaque appel :

>>> entry = Entry.objects.get(id=1)
>>> entry.authors.all()  # query performed
>>> entry.authors.all()  # query performed again

Soyez prudent dans la lecture du code des gabarits, le système des gabarits ne permet pas d’utiliser des parenthèses, mais les objets exécutables sont appelés automatiquement, masquant la distinction ci-dessus.

Soyez prudent avec vos propres propriétés personnalisées, il vous revient d’implémenter leur mise en cache au besoin, par exemple en utilisant le décorateur cached_property.

Utilisation de la balise de gabarit with¶

Pour faire usage du comportement de cache de QuerySet, il peut être nécessaire d’utiliser la balise de gabarit with.

Utilisation de iterator()¶

Lorsque vous manipulez un grand nombre d’objets, le comportement de cache de QuerySet peut provoquer une grosse utilisation de la mémoire. Dans ce cas, iterator() peut aider.

Utilisation de explain()¶

QuerySet.explain() apporte des informations détaillées sur la façon dont la base de données exécute les requêtes, y compris les index et jointures utilisées. Ces détails peuvent aider à trouver les requêtes qui pourraient être réécrites plus efficacement ou à identifier des index qui pourraient être ajoutés pour améliorer les performances.

Utilisation de RawSQL¶

Une méthode moins portable mais plus puissante est d’utiliser l’expression RawSQL qui permet d’ajouter explicitement du code SQL dans une requête. Si cela ne suffit toujours pas :

Utilisation de SQL brut¶

Écrivez votre propre code SQL pour sélectionner des données ou remplir les modèles. Utilisez django.db.connection.queries pour examiner ce que Django écrit pour vous et considérez cela comme un point de départ.

Utilisation de QuerySet.select_related() et prefetch_related()¶

Il faut bien comprendre select_related() et prefetch_related() et les utiliser :

• dans les gestionnaires (par défaut ou non) lorsque cela fait sens. Ayez conscience des endroits où les gestionnaires sont (ou ne sont pas) utilisés ; ce n’est pas toujours évident de le savoir, ne faites donc pas de simples suppositions.

• dans du code de vues ou d’autres couches, en faisant potentiellement appel à prefetch_related_objects() lorsque c’est nécessaire.

Utilisation de QuerySet.values() et values_list()¶

Lorsque vous ne voulez qu’obtenir un dictionnaire ou une liste de valeurs sans avoir besoin d’objets modèles de l’ORM, faites bon usage de values(). Cette méthode peut être utile pour remplacer des objets modèles dans le code des gabarits ; tant que les dictionnaires résultants possèdent les mêmes attributs que ceux qui sont utilisés dans le gabarit, tout va bien.

Utilisation de QuerySet.defer() et only()¶

Utilisez defer() et only() quand vous savez à l’avance que vous n’aurez pas besoin de certaines colonnes de base de données (ou non utiles dans la plupart des cas) afin d’éviter de les charger. Notez que si vous les utilisez quand même, l’ORM devra les charger à l’aide d’une nouvelle requête, ce qui peut potentiellement aggraver la situation quand cette technique n’est pas utilisée à bon escient.

N’utilisez pas trop agressivement les champs différés sans profilage car la base de données doit lire sur le disque la plupart des données non textuelles et non VARCHAR d’un enregistrement des résultats, même lorsqu’elle finit par n’exploiter que quelques colonnes. Les méthodes defer() et only() sont particulièrement adéquates lorsqu’on peut éviter de charger de grandes quantités de données textuelles ou quand la valeur de certains champs est coûteuse en terme de conversion en Python. Comme toujours, profilez d’abord, optimisez ensuite.

Utilisation de QuerySet.contains(obj)¶

…si vous voulez uniquement savoir si obj est présent dans le résultat de requête, au lieu de if obj in queryset.

Utilisation de QuerySet.count()¶

…si vous n’avez besoin que du nombre de lignes, et évitez len(queryset).

Utilisation de QuerySet.exists()¶

…si vous voulez uniquement savoir qu’il y a au moins un résultat, et évitez if queryset.

Mais :

Ne pas abuser de contains(), count() et exists()¶

Si vous allez avoir besoin de données réelles du QuerySet, évaluez-le immédiatement.

Par exemple, si on dispose d’un modèle Group ayant une relation plusieurs-à-plusieurs vers User, le code suivant est optimal :

members = group.members.all()

if display_group_members:
    if members:
        if current_user in members:
            print("You and", len(members) - 1, "other users are members of this group.")
        else:
            print("There are", len(members), "members in this group.")

        for member in members:
            print(member.username)
    else:
        print("There are no members in this group.")

Il est optimal car :

1. Comme les objets QuerySet sont différés, aucune requête de base de données n’est exécutée si display_group_members vaut False.

2. Le stockage de group.members.all() dans la variable members permet de réutiliser son résultat mis en cache.

3. La ligne if members: provoque l’appel à QuerySet.__bool__(), ce qui provoque aussi l’exécution de la requête group.members.all() dans la base de données. S’il n’y a pas de résultats, elle renvoie False, sinon True.

4. La ligne if current_user in members: vérifie si l’utilisateur est dans le cache de résultats, donc aucune requête de base de données supplémentaire n’est effectuée.

5. L’emploi de len(members) appelle QuerySet.__len__(), réutilisant le résultat mis en cache, donc toujours sans requête supplémentaire vers la base de données.

6. La boucle for member utilise les données du cache.

Au total, le code effectue une ou zéro requête de base de données. La seule optimisation explicite effectuée est l’emploi de la variable members. Si on avait utilisé QuerySet.exists() pour le if, QuerySet.contains() pour le in ou QuerySet.count() pour le nombre total, cela aurait généré à chaque fois des requêtes supplémentaires.

Utilisation de QuerySet.update() et delete()¶

Plutôt que de récupérer un ensemble d’objets, de définir certaines valeurs et de les enregistrer individuellement, utilisez une instruction SQL UPDATE groupée au moyen de QuerySet.update(). De la même façon, effectuez des suppressions groupées chaque fois que c’est possible.

Notez cependant que des méthodes de mise à jour groupées ne peuvent pas appeler les méthodes save() et delete() des instances individuelles, ce qui signifie que tout comportement spécialisé que vous auriez ajouté avec ces méthodes ne sera pas exécuté, y compris tout ce qui découle de l’utilisation des signaux attachés aux objets de base de données.

Utilisation directe de valeurs de clé étrangère¶

Si vous n’avez besoin que de la valeur d’une clé étrangère, utilisez la valeur qui est déjà stockée dans l’objet que vous manipulez, plutôt que de récupérer tout l’objet lié pour simplement disposer de sa clé primaire. Par exemple, faites :

entry.blog_id

au lieu de :

entry.blog.id

Ne pas trier les résultats sans raison¶

Le tri n’est pas gratuit ; chaque champ de tri est une opération que la base de données doit effectuer. Si un modèle possède un ordre de tri par défaut (Meta.ordering) et que vous n’en avez pas besoin, vous pouvez l’enlever sur un QuerySet en appelant order_by() sans paramètre.

L’ajout d’un index à votre base de données peut aider à améliorer les performances de tri.

Création groupée¶

Lors de la création d’objets, utilisez si possible la méthode bulk_create() pour réduire le nombre de requêtes SQL. Par exemple :

Entry.objects.bulk_create(
    [
        Entry(headline="This is a test"),
        Entry(headline="This is only a test"),
    ]
)

…est préférable à :

Entry.objects.create(headline="This is a test")
Entry.objects.create(headline="This is only a test")

Notez qu’il existe un certain nombre de restrictions à cette méthode, il s’agit donc de s’assurer qu’elle correspond à votre cas d’utilisation.

Mise à jour groupée¶

Lors de la mise à jour d’objets, utilisez si possible la méthode bulk_update() pour réduire le nombre de requêtes SQL. Étant donné une liste ou un résultat de requête d’objets :

entries = Entry.objects.bulk_create(
    [
        Entry(headline="This is a test"),
        Entry(headline="This is only a test"),
    ]
)

L’exemple suivant :

entries[0].headline = "This is not a test"
entries[1].headline = "This is no longer a test"
Entry.objects.bulk_update(entries, ["headline"])

…est préférable à :

entries[0].headline = "This is not a test"
entries[0].save()
entries[1].headline = "This is no longer a test"
entries[1].save()

Notez qu’il existe un certain nombre de restrictions à cette méthode, il s’agit donc de s’assurer qu’elle correspond à votre cas d’utilisation.

Insertion groupée¶

Lors de l’insertion d’objets dans des champs ManyToManyField, utilisez add() avec plusieurs objets pour réduire le nombre de requêtes SQL. Par exemple

my_band.members.add(me, my_friend)

…est préférable à :

my_band.members.add(me)
my_band.members.add(my_friend)

…où Bands et Artists sont liés par une relation plusieurs-à-plusieurs.

Lors de l’insertion de plusieurs paires d’objets dans des champs ManyToManyField ou lorsque la table personnalisée through est définie, utilisez la méthode bulk_create() pour réduire le nombre de requêtes SQL. Par exemple

PizzaToppingRelationship = Pizza.toppings.through
PizzaToppingRelationship.objects.bulk_create(
    [
        PizzaToppingRelationship(pizza=my_pizza, topping=pepperoni),
        PizzaToppingRelationship(pizza=your_pizza, topping=pepperoni),
        PizzaToppingRelationship(pizza=your_pizza, topping=mushroom),
    ],
    ignore_conflicts=True,
)

…est préférable à :

my_pizza.toppings.add(pepperoni)
your_pizza.toppings.add(pepperoni, mushroom)

…où Pizza et Topping ont une relation plusieurs-à-plusieurs. Notez qu’il existe un certain nombre de restrictions à cette méthode, il s’agit donc de s’assurer qu’elle correspond à votre cas d’utilisation.

Suppression groupée¶

Lors de la suppression d’objets de champs ManyToManyField, utilisez remove() avec plusieurs objets pour réduire le nombre de requêtes SQL. Par exemple

my_band.members.remove(me, my_friend)

…est préférable à :

my_band.members.remove(me)
my_band.members.remove(my_friend)

…où Bands et Artists sont liés par une relation plusieurs-à-plusieurs.

Lors de la suppression de plusieurs paires d’objets de champs ManyToManyField, utilisez delete() sur une expression Q avec plusieurs instances de modèle through pour réduire le nombre de requêtes SQL. Par exemple

from django.db.models import Q

PizzaToppingRelationship = Pizza.toppings.through
PizzaToppingRelationship.objects.filter(
    Q(pizza=my_pizza, topping=pepperoni)
    | Q(pizza=your_pizza, topping=pepperoni)
    | Q(pizza=your_pizza, topping=mushroom)
).delete()

…est préférable à :

my_pizza.toppings.remove(pepperoni)
your_pizza.toppings.remove(pepperoni, mushroom)

…où Pizza et Topping sont liés par une relation plusieurs-à-plusieurs.