Partage via

Référence DTU

  • Article

S’applique à : Azure SQL Database

Une unité de transaction de base de données (DTU) est une unité de mesure qui représente un mélange de mesures de processeur, de mémoire, de lectures et d’écritures. Les caractéristiques physiques (processeur, mémoire, E/S) associées à chaque mesure DTU sont étalonnées à l’aide d’un test d’évaluation qui simule une charge de travail de base de données réelle. Cet article résume le test d’évaluation de DTU et partage des informations sur le schéma, les types de transactions utilisés, la combinaison de charges de travail, les utilisateurs et le rythme, les règles de mise à l’échelle et les métriques associées au test d’évaluation.

Pour des informations générales sur le modèle d’achat DTU, consultez Vue d’ensemble du modèle d’achat DTU.

Résumé du test d’évaluation

Le test d’évaluation de DTU mesure les performances d’une série d’opérations de base de données basiques qui se produisent le plus fréquemment dans les charges de travail de traitement transactionnel en ligne (OLTP). Bien qu’il ait été conçu pour les environnements cloud, le schéma de base de données, le remplissage des données et les transactions ont été formulés pour représenter les éléments de base couramment utilisés dans les charges de travail OLTP.

Mise en corrélation des résultats du test d’évaluation avec les performances réelles de la base de données

Il est important de comprendre que tous les tests d’évaluation fournissent uniquement des résultats représentatifs et indicatifs. Les taux de transaction obtenus avec l’application d’évaluation ne seront pas les mêmes que ceux qui peuvent être atteints avec d’autres applications. Le test d’évaluation comprend un ensemble de différents types de transactions qui s’exécutent sur un schéma contenant une plage de tables et de types de données. Si le test d’évaluation exécute les mêmes opérations de base communes à toutes les charges de travail OLTP, il n’a pas vocation à représenter une classe de base de données ou d’application spécifique. L’objectif de ce test est de fournir des indications quant aux performances relatives d’une base de données, auxquelles on peut s’attendre après un changement de taille de calcul.

En réalité, les bases de données varient en termes de taille et de complexité. Elles supportent diverses charges de travail et réagissent de différentes façons. Par exemple, une application gourmande en E/S peut atteindre rapidement les seuils d’E/S, de la même manière qu’une application gourmande en ressources processeur peut atteindre rapidement les limites processeur. Rien ne peut garantir qu’une base de données particulière évoluera de la même façon que le test d’évaluation sous une charge plus importante.

Le test d’évaluation et sa méthodologie sont décrits plus en détail dans cet article.

schéma

Le schéma a été conçu de façon suffisamment variée et complexe pour prendre en charge un large éventail d’opérations. Le test d’évaluation s’exécute sur une base de données composée de six tables. Les tables se répartissent en trois catégories : taille fixe, extensibles et évolutives. Il existe deux tables de taille fixe, trois tables extensibles et une table évolutive. Les tables de taille fixe comportent un nombre constant de lignes. Les tables évolutives ont une cardinalité proportionnelle aux performances de la base de données, mais qui ne varie pas pendant le point de référence. La table évolutive est dimensionnée à la manière d’une table extensible sur la charge initiale, mais la cardinalité change pendant l’exécution du test d’évaluation à mesure que des lignes sont insérées et supprimées.

Le schéma inclut divers types de données, notamment des entiers, des valeurs numériques, des caractères et des valeurs date/heure. Le schéma inclut des clés primaires et secondaires, mais aucune clé étrangère ; autrement dit, il n’y a pas de contraintes d’intégrité référentielle entre les tables.

Un programme de génération de données génère les données pour la base de données initiale. Les entiers et les données numériques sont générés à l’aide de différentes stratégies. Dans certains cas, les valeurs sont distribuées de façon aléatoire sur une plage. Dans d’autres cas, un ensemble de valeurs est permuté de façon aléatoire pour garantir une distribution spécifique. Les champs de texte sont générés à partir d’une liste pondérée de mots permettant de produire des données réalistes.

La base de données est dimensionnée selon un facteur d’échelle. Le facteur d’échelle (« SF ») détermine la cardinalité des tables extensibles et évolutives. Comme décrit dans la section « Utilisateurs et rythme » ci-dessous, la taille de la base de données, le nombre d’utilisateurs et les performances maximales s’adaptent tous au prorata des uns des autres.

Transactions

La charge de travail se compose de neuf types de transactions, comme indiqué dans le tableau ci-dessous. Chaque transaction est conçue pour mettre en évidence un ensemble particulier de caractéristiques système dans le moteur de base de données et le matériel système, en les distinguant clairement des autres transactions. Cette approche permet d’évaluer plus facilement l’impact des différents composants sur les performances globales. Par exemple, la transaction « Read Heavy » génère un nombre important d’opérations de lecture à partir du disque.

Type de transaction Description
Read Lite SÉLECTION ; dans la mémoire ; lecture seule
Read Medium SÉLECTION ; principalement dans la mémoire ; lecture seule
Read Heavy SÉLECTION ; principalement hors de la mémoire ; lecture seule
Update Lite MISE À JOUR ; dans la mémoire ; lecture-écriture
Update Heavy MISE À JOUR ; principalement hors de la mémoire ; lecture-écriture
Insert Lite INSERTION ; dans la mémoire ; lecture-écriture
Insert Heavy INSERTION ; principalement hors de la mémoire ; lecture-écriture
DELETE SUPPRESSION ; combinaison de ressources dans la mémoire et hors de la mémoire ; lecture-écriture
CPU Heavy SÉLECTION ; dans la mémoire ; charge UC relativement importante ; lecture seule

Combinaison de charges de travail

Les transactions sont sélectionnées de manière aléatoire à partir d’une distribution pondérée avec la combinaison générale suivante. La combinaison générale présente un ratio lecture/écriture d’environ 2:1.

Type de transaction % de la combinaison
Read Lite 35
Read Medium 20
Read Heavy 5
Update Lite 20
Update Heavy 3
Insert Lite 3
Insert Heavy 2
DELETE 2
CPU Heavy 10

Utilisateurs et rythme

La charge de travail d’évaluation est pilotée par un outil qui envoie des transactions sur un ensemble de connexions afin de simuler le comportement d’un nombre d’utilisateurs simultanés. Bien que l’ensemble des connexions et transactions soient générées de façon automatique, nous appelons ces connexions utilisateurs par souci de simplicité. Bien que chaque utilisateur fonctionne indépendamment de tous les autres, tous exécutent le même cycle d’étapes, comme indiqué ci-dessous :

  1. Établir une connexion à la base de données.
  2. Répéter jusqu'à obtention du signal de sortie :
    • Sélection d’une transaction de façon aléatoire (à partir d’une distribution pondérée)
    • Exécution de la transaction sélectionnée et évaluation du temps de réponse
    • Délai d’attente
  3. Fermer la connexion à la base de données.
  4. Quitter.

Le délai (à l’étape 2c) est sélectionné au hasard, mais avec une distribution de 1 seconde en moyenne. Chaque utilisateur peut donc, en moyenne, générer au maximum une transaction par seconde.

Règles de mise à l’échelle

Le nombre d’utilisateurs est déterminé par la taille de la base de données (en unités de facteur d’échelle). On compte un seul utilisateur pour cinq unités de facteur d’échelle. En raison du délai, un même utilisateur peut générer, en moyenne, au maximum une transaction par seconde.

Par exemple, une base de données utilisant un facteur d’échelle de 500 (SF = 500) comportera 100 utilisateurs et pourra atteindre un taux maximum de 100 TPS. Pour augmenter le taux de TPS, la base de données doit être plus volumineuse et comporter un plus grand nombre d’utilisateurs.

Durée de la mesure

Pour être reconnu valide, un test d’évaluation doit s’effectuer sur une durée de mesure constante d’au moins une heure.

Mesures

Le débit et le temps de réponse constituent les principaux indicateurs du test d’évaluation.

  • Le débit est la mesure de performance la plus importante dans ce test d’évaluation. Il est exprimé en transactions par unité de temps et tient compte de tous les types de transactions.
  • Le temps de réponse permet de mesurer la prévisibilité des performances. La limite de temps de réponse varie en fonction de la classe de service, les classes de service plus élevées devant satisfaire à des exigences de temps de réponse plus serrées, comme indiqué ci-dessous.
Classe de service Mesure du débit Temps de réponse requis
Premium Transactions par seconde 95e centile à 0,5 seconde
Standard Transactions par minute 90e centile à 1 seconde
De base Transactions par heure 80e centile à 2 secondes

Notes

Les mesures de temps de réponse sont spécifiques au point de référence DTU. Les temps de réponse pour les autres charges de travail dépendent de la charge de travail et varient.

Étapes suivantes

Pour en savoir plus sur les modèles d’achat et les concepts associés, consultez les articles suivants :