Impact de la charge système sur les performances

Les considérations sur la définition d'un index multi-colonnes s'arrêtent souvent dès que l'index est utilisé pour une requête en cours d'optimisa­tion. Néanmoins, la raison pour laquelle l'optimiseur n'utilise pas un index n'est généralement pas parce qu'il ne s'agit pas du bon index pour cette requête. Habituellement, il ne l'utilise pas parce qu'il est plus efficace de faire un parcours complet de table. Cela ne signifie pas que l'index est optimal pour la requête.

L'exemple précédent a montré des difficultés pour reconnaître le bon ordre des colonnes dans un index à partir du plan d'exécution. Très souvent, les informations de prédicat sont bien cachées, donc vous devez les rechercher spécifiquement pour vérifier l'utilisation optimale des index.

Par exemple, SQL Server Management Studio montre seulement les infor­mations de prédicat dans une infobulle lorsque vous déplacez le curseur de la souris sur l'opération d'index—aussi sur cette page web. Le plan d'exécution suivant utilise l'index SCALE_SLOW ; du coup, il montre la condition sur ID2 comme un prédicat de filtre (juste « Predicate », sans le terme « Seek »). Obtenir l'information de prédicat à partir du plan d'exécution de MySQL ou PostgreSQL est encore plus bizarre. L'Annexe A dispose des détails.

Peu importe comment est affichée l'information du prédicat, cette infor­mation a un impact important sur les performances, tout spécialement quand le système grossit. Rappelez-vous que ce n'est pas seulement le volume de données qui grossit, mais aussi le nombre d'accès. Ceci est encore un autre paramètre de la scalabilité.

La Figure 3.4 graphe le temps de réponse comme une fonction du temps d'accès. Le volume de données reste constant. Cela montre le temps d'exécution de la même requête et utilise toujours la section avec le plus grand volume de données. Cela signifie que le dernier point de la Figure 3.2 correspond au premier point dans ce graphe.

La ligne pointillée trace le temps de réponse lors de l'utilisation de l'index SCALE_SLOW. Elle atteint jusqu'à 32 secondes si 25 requêtes s'exécutent en même temps. En comparant avec le temps de réponse sans charge en arrière-plan (cela pourrait être le cas dans votre environnement de développement), cela prend 30 fois plus de temps. Même si vous avez une copie complète de la base de données en production dans votre environnement de développement, la charge de fond en production peut encore causer plus de lenteur à l'exécution de la requête.

La ligne solide montre le temps de réponse en utilisant l'index SCALE_FAST. Il n'y a pas de prédicat de filtre. Le temps de réponse reste bien en-dessous des deux secondes même si 25 requêtes sont exécutées en même temps.

Des temps de réponse suspects sont souvent pris à la légère lors du développement. Ceci est principalement dû au fait que nous nous atten­dons à ce que nous ayons du « matériel plus performant en production », ce qui impliquerait de meilleures performances. Généralement, on observe l'inverse car l'infrastructure en production est plus complexe et accumule les latences qui interviennent peu dans l'environnement de développement. Même en testant sur une infrastructure équivalente à celle en production, la charge en tâche de fond peut toujours causer des temps de réponse différents. Dans la prochaine section, nous verrons qu'il n'est pas raisonnable, en général, de s'attendre à de meilleurs temps de réponse avec un plus gros matériel.