Partager via

Benchmark DTU

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.

Mettre en corrélation les résultats des benchmarks 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 nécessitant beaucoup d’E/S peut atteindre les seuils d’E/S plus tôt, ou une application nécessitant beaucoup de CPU peut atteindre les limites du processeur plus tôt. 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, mise à l’échelle 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 mises à l’échelle 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 comme une table extensible lors du chargement initial, mais la cardinalité change au cours de l'exécution du benchmark à 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 se mettent tous à l’échelle en proportion les uns par rapport aux autres.

Opérations

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 Descriptif
Lire Lite SÉLECTION ; dans la mémoire ; lecture seule
Lire Medium SÉLECTION ; principalement dans la mémoire ; lecture seule
Lire lourd SÉLECTION ; principalement pas en mémoire ; lecture seule
Mettre à jour Lite MISE À JOUR ; dans la mémoire ; lecture-écriture
Mettre à jour importante MISE À JOUR ; principalement hors de la mémoire ; lecture-écriture
Insérer Lite INSERTION ; dans la mémoire ; lecture-écriture
Insérer heavy INSERTION ; principalement hors de la mémoire ; lecture-écriture
Supprimer SUPPRESSION ; combinaison de ressources dans la mémoire et hors de la mémoire ; lecture-écriture
Processeur lourd 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 % du mélange
Lire Lite 35
Lire Medium 20
Lire lourd 5
Mettre à jour Lite 20
Mettre à jour heavy 3
Insérer Lite 3
Insérer lourd 2
Supprimer 2
Processeur lourd 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
    • En attente d’un délai.
  3. Fermer la connexion à la base de données.
  4. Quittez.

Le délai de synchronisation (à l’étape 2c) est sélectionné au hasard, mais avec une distribution ayant une moyenne de 1,0 seconde. 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
Prime Transactions par seconde 95e centile à 0,5 seconde
Standard Transactions par minute 90e percentile à 1,0 seconde
Essentiel Transactions par heure 80e percentile à 2,0 secondes

Remarque

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.

Contenu connexe

  • Last updated on