Bonnes pratiques pour évaluer les performances d’Azure Database pour MySQL – Serveur flexible

2025-06-23

Les performances constituent une caractéristique principale de toute application et il est essentiel de définir une stratégie claire d’analyse et d’évaluation des performances d’une base de données lors de la gestion des exigences de charge de travail variables d’une application.

Cet article fournit des considérations et des bonnes pratiques pour l’exécution de benchmarks de performances sur un serveur flexible Azure Database pour MySQL.

Tests des performances

L’évaluation des performances des systèmes de base de données relationnelle peut à première vue sembler être une tâche futile. Après tout, il est assez simple d’évaluer manuellement les performances des requêtes individuelles et même de lancer des tests synthétiques simples à l’aide de l’un des outils d’évaluation disponibles. Ces types de tests prennent peu de temps et produisent rapidement des résultats faciles à comprendre.

Toutefois, l’évaluation des performances des vrais systèmes de production demande beaucoup plus d’efforts. Il est difficile de concevoir, d’implémenter et d’exécuter des tests vraiment représentatifs des charges de travail de production. Il est encore plus difficile de prendre des décisions concernant les piles de données de production en fonction des résultats d’une série de points de référence effectués dans un environnement isolé.

Méthodologies des tests des performances

Points de référence synthétiques

Le test synthétique est conçu pour contraindre un système de base de données à l’aide d’échantillons de charge de travail artificiels qui simulent des résultats reproductibles dans un environnement de base de données. Cela permet aux clients d’effectuer des comparaisons entre plusieurs environnements pour évaluer la ressource de base de données appropriée pour leurs déploiements de production.

Plusieurs avantages sont associés à l’utilisation de points de référence synthétiques. Par exemple, ils :

Sont prévisibles, reproductibles et permettent des tests sélectifs (par exemple, des tests en écriture seule, des tests en lecture seule, un mélange de tests en écriture et en lecture, et des tests ciblés par rapport à une table).
Fournissent des résultats globaux qui peuvent être représentés à l’aide de mesures simples (par exemple, « requêtes par seconde », « transactions par seconde », etc.).
Ne nécessitent pas de connaissances propres à une application ou à un environnement à créer et exécuter.
Peuvent être effectués rapidement sans préparation ou presque. Toutefois, il existe également des inconvénients associés, car :
Les échantillons de charges de travail artificielles ne sont pas représentatifs du trafic réel d’application.
Les résultats ne peuvent pas être utilisés pour prévoir avec précision les performances des charges de travail de production.
Ils peuvent ne pas exposer les caractéristiques de performances propres à un produit lorsqu’ils sont utilisés pour tester différents produits de base de données.
Il est facile de mal effectuer les tests et de produire des résultats encore moins représentatifs.

Les tests synthétiques sont utiles pour des comparaisons rapides entre les produits. Vous pouvez également les utiliser pour implémenter des mécanismes de monitoring des performances continu. Par exemple, vous pouvez exécuter une suite de tests tous les week-ends pour valider les performances de référence de votre système de base de données, détecter les anomalies et prédire les modèles de performances à long terme (par exemple, la dégradation de la latence des requêtes suite à la croissance des données).

Points de référence concrets

Avec des tests réels, des échantillons de charge de travail qui ressemblent étroitement au trafic de production sont présentés à la base de données. Vous pouvez y parvenir directement en reproduisant un journal des requêtes de production et en mesurant les performances de la base de données. Vous pouvez également y parvenir indirectement, en exécutant le test au niveau de l’application et en mesurant les performances de l’application sur un serveur de base de données précis.

Il existe plusieurs avantages associés à l’utilisation de points de référence réels, car ils :

Fournissent une vue précise des performances du système dans des conditions réelles de production.
Peuvent révéler des caractéristiques propres à une application ou à une base de données que les tests synthétiques simplifiés ne feraient pas.
Aident dans la planification de la capacité liée au développement des applications.

Il existe également certains inconvénients : les points de référence réels :

Sont difficiles à concevoir et à exécuter.
Doivent être conservés pour garantir la pertinence à mesure que l’application évolue.
Fournissent des résultats significatifs uniquement dans le contexte d’une application donnée.

Lorsque vous vous préparez à un changement majeur dans votre environnement, par exemple lors du déploiement d’un nouveau produit de base de données, il est recommandé d’utiliser des tests réels. Dans une telle situation, une exécution de points de référence complète utilisant la charge de travail de production réelle est d’une grande aide. Elle fournit non seulement des résultats précis dont vous pouvez avoir faire confiance, mais également supprime ou du moins réduit considérablement le nombre d’« inconnues » sur votre système.

Choisir la « bonne » méthodologie de test

La « bonne » méthodologie de test pour vos besoins dépend entièrement de l’objectif de vos tests.

Si vous souhaitez comparer rapidement différents produits de base de données à l’aide d’échantillons de données artificielles et de charges de travail, vous pouvez utiliser en toute sécurité un programme de points de référence existant qui génère des données et exécute le test pour vous.

Pour évaluer avec précision les performances d’une application réelle que vous envisagez d’exécuter sur un nouveau produit de base de données, vous devez effectuer des tests de points de référence réels. Chaque application a un ensemble unique d’exigences et de caractéristiques de performances, et il est recommandé d’inclure des tests de points de référence réels dans toutes les évaluations de performances.

Pour obtenir des instructions sur la préparation et l’exécution de points de référence synthétiques et réels, consultez les sections suivantes plus loin dans cette publication :

Préparation et exécution de tests synthétiques
Préparation et exécution de tests réels

Meilleures pratiques pour les tests de performances

Recommandations propres au serveur

Taille du serveur

Lors du lancement d’instances de serveur flexible Azure Database pour MySQL pour effectuer un benchmark, utilisez un niveau d’instance azure Database pour MySQL Flexible Server, une référence SKU et un nombre d’instances qui correspondent à votre environnement de base de données actuel.

Par exemple :

Si votre serveur actuel a un processeur huit cœurs et 64 Go de mémoire, il est préférable de choisir une instance basée sur la référence SKU Standard_E8ds_v4.
Si votre environnement de base de données actuel utilise des réplicas en lecture, utilisez les réplicas en lecture d’un serveur flexible Azure Database pour MySQL.

En fonction des résultats de vos tests de points de référence, vous pouvez décider d’utiliser des tailles et des quantités différentes d’instances en production. Toutefois, il est toujours recommandé de s’assurer que les spécifications initiales des instances de test sont proches des spécifications actuelles de votre serveur afin de fournir une comparaison d’éléments similaires plus précise.

Configuration du serveur

Si l’application/point de référence nécessite que certaines fonctionnalités de base de données soient activées, avant d’exécuter le test de points de référence, ajustez les paramètres du serveur en conséquence. Par exemple, vous pourriez avoir besoin de :

Définir un fuseau horaire autre que celui par défaut sur le serveur.
Définir un paramètre « max_connections » personnalisé si la valeur par défaut n’est pas suffisante.
Configurez le pool de threads si votre instance de serveur flexible Azure Database pour MySQL exécute la version 8.0.
Activer les journaux des requêtes lentes si vous prévoyez de les utiliser en production afin de pouvoir analyser les goulots d’étranglement.

D’autres paramètres, tels que ceux liés à la taille de différentes mémoires tampons et caches de base de données, sont déjà prétunés dans le serveur flexible Azure Database pour MySQL, et vous pouvez les laisser définis initialement à leurs valeurs par défaut. Bien que vous puissiez les modifier, il est préférable d’éviter d’apporter des modifications aux paramètres de serveur, sauf si vos points de référence de performances montrent qu’une modification donnée améliore effectivement les performances.

Lorsque vous effectuez des tests comparant le serveur flexible Azure Database pour MySQL à d’autres produits de base de données, veillez à activer toutes les fonctionnalités que vous prévoyez d’utiliser en production sur vos bases de données de test. Par exemple, si vous n’activez pas la haute disponibilité, les sauvegardes et les réplicas en lecture redondants interzone dans votre environnement de test, vos résultats peuvent ne pas refléter avec précision les performances réelles.

Recommandations propres au client

Tous les points de référence de performance impliquent l’utilisation d’un client. Par conséquent, quelle que soit la méthodologie d’évaluation choisie, veillez à prendre en compte les recommandations côté client suivantes.

Vérifiez que les instances clientes existent dans le même réseau virtuel Azure que l’instance de serveur flexible Azure Database pour MySQL que vous testez. Pour les applications sensibles à la latence, il est recommandé de placer les instances clientes dans la même zone de disponibilité que le serveur de base de données.
Si une application de production est censée s’exécuter sur plusieurs instances (par exemple, une flotte de serveurs d’applications derrière un équilibreur de charge), il est recommandé d’utiliser plusieurs instances clientes lors de l’exécution du point de référence.
Assurez-vous que toutes les instances clientes disposent d’une capacité de calcul, de mémoire, d’E/S et de réseau adéquate pour gérer le point de référence. En d’autres termes, les clients doivent pouvoir produire des requêtes plus rapidement que le moteur de base de données ne peut en gérer. Tous les systèmes d’exploitation fournissent des outils de diagnostic (tels que « top », « htop », « dstat » ou « iostat » sur Linux) qui peuvent vous aider à diagnostiquer l’utilisation des ressources sur les instances clientes. Il est recommandé d’utiliser ces outils et de vous assurer que toutes les instances clientes disposent toujours d’une capacité de processeur, de mémoire, de réseau et d’E/S de rechange pendant l’exécution du point de référence.

Même avec une référence SKU élevée, une seule instance cliente peut ne pas toujours être en mesure de générer des requêtes assez rapidement pour saturer la base de données. En fonction de la configuration de test, le serveur flexible Azure Database pour MySQL peut être capable de gérer des centaines de milliers de demandes de lecture/écriture par seconde, ce qui peut être plus qu’un seul client peut prendre en charge. Pour éviter une contention côté client lors de tests de performances lourds, il est donc courant d’exécuter un point de référence à partir de plusieurs instances clientes en parallèle.

Important

Si vous évaluez votre application à l’aide d’un script de générateur de trafic ou d’un outil tiers (comme Apache Benchmark, Apache JMeter ou Siege), vous devez également évaluer l’instance sur laquelle l’outil s’exécute à l’aide des recommandations présentées précédemment.

Préparation et exécution de tests synthétiques

Les outils d’évaluation synthétiques tels que sysbench sont faciles à installer et à exécuter, mais ils nécessitent généralement un certain niveau de configuration et de réglage avant qu’un point de référence donné puisse obtenir des résultats optimaux.

Nombre et taille des tables

Le nombre et la taille des tables générées avant l’évaluation doivent être élevés. Par exemple, les tests effectués sur une table de100 000 lignes sont peu susceptibles de fournir des résultats utiles, car un tel jeu de données est probablement plus petit que pratiquement n’importe quelle base de données réelle. À titre de comparaison, un point de référence utilisant plusieurs tables (par exemple, 10 à 25) avec 5 millions de lignes chacune est certainement une représentation plus réaliste de la charge de travail en temps réel.

Mode Test

Avec la plupart des outils de point de référence (y compris le populaire sysbench), vous pouvez définir le type de charge de travail que vous souhaitez exécuter sur le serveur. Par exemple, l’outil peut générer :

Des requêtes en lecture seule avec une syntaxe identique, mais des paramètres différents.
Des requêtes en lecture seule de différents types (sélections de points, sélections de plage, sélections avec tris, etc.).
Des instructions en écriture seule qui modifient des lignes individuelles ou des plages de lignes.
Un mélange d’instructions en lecture/écriture.

Vous pouvez utiliser des charges de travail en lecture seule ou en écriture seule si vous souhaitez tester les performances et la scalabilité de la base de données dans ces scénarios spécifiques. Toutefois, un point de référence représentatif doit généralement inclure un bon mélange d’instructions en lecture/écriture parce qu’il s’agit du type de charge de travail que la plupart des bases de données OLTP doivent gérer.

Niveau de concurrence

Le niveau de concurrence correspond au nombre de threads exécutant simultanément des opérations sur la base de données. La plupart des outils de points de référence utilisent un thread unique par défaut, ce qui n’est pas représentatif des environnements de base de données réels, car les bases de données sont rarement utilisées par un seul client à la fois.

Pour tester les performances maximales théoriques d’une base de données, utilisez le processus suivant :

Exécutez plusieurs tests à l’aide d’un nombre de threads différent pour chaque test. Par exemple, commencez avec 32 threads, puis augmentez le nombre de threads pour chaque test suivant (64, 128, 256, etc.).
Continuez à augmenter le nombre de threads jusqu’à ce que les performances de la base de données se stabilisent. Il s’agit de vos performances théoriques maximales.
Lorsque vous déterminez que les performances de la base de données cessent d’augmenter à un niveau de concurrence donné, vous pouvez toujours essayer d’augmenter le nombre de threads plusieurs fois, ce qui indiquera si les performances restent stables ou commencent à se dégrader. Pour plus d’informations, consultez le billet de blog Benchmarking Azure Database for MySQL – Flexible Server using Sysbench.

Préparation et exécution de tests réels

Chaque application est unique en matière de caractéristiques de données et d’exigences de performances. Par conséquent, il est difficile de trouver une liste universelle d’étapes qui serait suffisante pour préparer et exécuter un point de référence réel représentatif dans un environnement de base de données arbitraire.

Les idées présentées dans cette section sont destinées à rendre un peu plus faciles les projets de test de performances.

Préparer les données de test

Avant d’effectuer des benchmarks de performances sur un serveur flexible Azure Database pour MySQL, assurez-vous que le serveur est rempli avec un échantillon représentatif de votre jeu de données de production.

Dans la mesure du possible, utilisez une copie complète du jeu de données de production. Lorsque ce n’est pas possible, utilisez les suggestions suivantes pour vous aider à déterminer quelles parties des données vous devez toujours inclure et quelles données vous pouvez laisser.

Le serveur de test doit inclure tous les objets (par exemple, les schémas, les tables, les fonctions et les procédures) qui sont directement utilisés par le point de référence. Chaque table doit être entièrement remplie, c’est-à-dire qu’elle doit contenir toutes les lignes qu’elle contient en production. Si les tables ne sont pas entièrement renseignées (par exemple, elles ne contiennent qu’un petit échantillon de l’ensemble de lignes), les résultats du point de référence ne seront pas représentatifs.
Excluez les tables utilisées par les applications de production, mais qui ne font pas partie du trafic opérationnel continu. Par exemple, si une base de données contient un jeu de données opérationnelles actives ainsi que des données historiques utilisées pour l’analytique, les données historiques peuvent ne pas être nécessaires pour exécuter des points de référence.
Remplissez toutes les tables que vous copiez sur le serveur de test avec des données de production réelles plutôt qu’avec des échantillons artificiels générés programmatiquement.

Concevoir des points de référence d’application

Le processus général pour exécuter des points de référence d’application est le suivant :

Créez une instance de serveur flexible Azure Database pour MySQL et remplissez-la avec une copie de vos données de production.
Déployez une copie de l’application dans Azure.
Configurez l’application pour utiliser l’instance de serveur flexible Azure Database pour MySQL.
Exécutez des tests de charge sur l’application et évaluez les résultats.

Cette approche est essentiellement utile lorsque vous pouvez facilement déployer une copie de votre application dans Azure. Elle vous permet d’effectuer une évaluation des performances de la manière la plus complète et la plus précise, mais il existe encore certaines recommandations à garder à l’esprit.

L’outil utilisé pour générer le trafic d’application doit pouvoir produire une combinaison de requêtes représentatives de votre charge de travail de production. Par exemple, ne testez pas en accédant à plusieurs reprises à la même URL d’application, car cela n’est probablement pas représentatif de la façon dont vos clients utilisent l’application dans la vie.
Le pool d’instances de client et d’application doit être suffisamment performant pour générer des requêtes, les gérer et recevoir des réponses de la base de données sans introduire de goulots d’étranglement.
Le niveau de concurrence (le nombre de requêtes parallèles générées par l’outil de benchmark) doit correspondre ou légèrement dépasser le niveau de concurrence maximal attendu observé dans votre application.

Concevoir des points de référence de base de données

Si vous ne pouvez pas déployer facilement une copie de votre application dans Azure, vous devez effectuer le point de référence en exécutant des instructions SQL directement sur la base de données. Pour ce faire, utilisez la procédure générale suivante :

Identifiez les instructions SQL qui apparaissent le plus souvent dans votre charge de travail de production.
En fonction des informations collectées à la première étape, préparez un grand échantillon d’instructions SQL à tester.
Créez un nœud serveur flexible Azure Database pour MySQL et remplissez-le avec une copie de vos données de production.
Lancez une ou plusieurs instances de client de machine virtuelle Azure dans Azure.
À partir des machines virtuelles, exécutez l’exemple de charge de travail SQL sur votre instance de serveur flexible Azure Database pour MySQL et évaluez les résultats.

Il existe deux approches principales pour générer la charge utile des tests (échantillons d’instructions SQL) :

Observez/enregistrez le trafic SQL qui se produit dans votre base de données actuelle, puis générez des échantillons SQL en fonction de ces observations. Pour plus d’informations sur l’enregistrement du trafic de requête à l’aide d’une combinaison de journaux d’audit et de journalisation lente des requêtes dans le serveur flexible Azure Database pour MySQL.
Utilisez les journaux de requêtes réels comme charge utile. Des outils tiers comme « Percona Playback» peuvent générer des charges de travail multithread basées sur les journaux des requêtes lentes MySQL.

Si vous décidez de générer manuellement un échantillon SQL, vérifiez que l’échantillon contient :

Un nombre suffisant d’instructions uniques.

Exemple : si vous déterminez que la charge de travail de production utilise 15 principaux types d’instructions, il ne suffit pas que l’échantillon contienne un total de 15 instructions (une par type). Pour un si petit échantillon, la base de données met facilement en cache les données requises en mémoire, ce qui rend le point de référence non représentatif. Fournissez plutôt un grand échantillon de requêtes pour chaque type d’instruction et utilisez les recommandations supplémentaires suivantes.
Instructions de différents types dans les bonnes proportions.

Exemple : si vous déterminez que votre charge de travail de production utilise 12 types d’instructions, il est probable que certains types d’instructions apparaissent plus souvent que d’autres. Votre échantillon doit refléter ces proportions : si la requête A apparaît 10 fois plus souvent que la requête B dans la charge de travail de production, elle doit également apparaître 10 fois plus souvent dans votre échantillon.
Paramètres de requête qui sont, de manière réaliste, aléatoires.

Si vous avez suivi les recommandations précédentes et que votre échantillon de requêtes contient des groupes de requêtes du même type/de la même syntaxe, les paramètres de ces requêtes doivent être aléatoires. Si l’échantillon contient un million de requêtes du même type et qu’elles sont toutes identiques (y compris les paramètres dans des conditions WHERE), les données requises seront facilement mises en cache dans la mémoire de la base de données, ce qui rend le point de référence non représentatif.
Ordre d’exécution des instructions qui est randomisé de manière réaliste.

Si vous suivez les recommandations précédentes et que la charge utile de votre test contient de nombreuses requêtes de différents types, vous devez exécuter ces requêtes dans un ordre réaliste. Par exemple, l’échantillon peut contenir 10 millions de SELECT et 1 million de UPDATE. Dans ce cas, l’exécution de toutes les requêtes SELECT avant toutes les requêtes UPDATE risque de ne pas être le meilleur choix, car cela n’est probablement pas la façon dont votre application exécute des requêtes dans la réalité. Il est plus probable que l’application entremêle les requêtes SELECT et les requêtes UPDATE, ce que votre test doit essayer de simuler.

Lorsque l’échantillon de requête est prêt, exécutez-le sur le serveur à l’aide d’un client MySQL en ligne de commande ou d’un outil tel que mysqlslapv.

Exécuter les tests

Que vous exécutiez un point de référence synthétique ou un test de performances d’application réel, il existe plusieurs règles générales à suivre pour être sûr d’obtenir des résultats plus représentatifs.

Exécuter des tests sur plusieurs types d’instances

Supposons que vous décidiez d’exécuter des points de référence sur un serveur db.r3.2xlarge et que vous constatez que les performances des applications/requêtes répondent déjà à vos besoins. Il est également recommandé d’exécuter les tests sur des types d’instances à la fois plus petits et plus grands, ce qui offre deux avantages :

Les tests avec des types d’instances plus petits peuvent toujours produire de bons résultats de performance et révéler des opportunités potentielles de réduction des coûts.
Les tests avec des types d’instances plus grands peuvent donner des idées ou des informations sur les options de scalabilité futures.

Mesurer à la fois les performances soutenues et maximales

La stratégie de test que vous choisissez doit vous fournir des réponses pour déterminer si la base de données fournit les éléments adéquats suivants :

Performances soutenues : fonctionnera-t-elle comme prévu avec la charge de travail normale, lorsque le trafic utilisateur est fluide et dans les niveaux attendus ?
Performances maximales : garantiront-elles la réactivité des applications pendant les pics de trafic ?

Tenez compte des consignes suivantes :

Assurez-vous que les exécutions de tests sont suffisamment longues pour évaluer les performances de la base de données dans un état stable. Par exemple, un test complexe qui ne dure que 10 minutes produira probablement des résultats inexacts, car les caches et les mémoires tampons de la base de données risquent ne pas être à plein régime en si peu de temps.
Les points de référence peuvent être beaucoup plus révélateurs et instructifs si les niveaux de charge de travail varient tout au long du test. Par exemple, si votre application reçoit généralement le trafic de 64 clients simultanés, démarrez le point de référence avec 64 clients. Ensuite, pendant que le test est toujours en cours d’exécution, ajoutez 64 clients supplémentaires pour déterminer le comportement du serveur lors d’un pic de trafic simulé.

Inclure des tests de blackout/brownout dans la procédure de point de référence

Les performances soutenues du serveur sont une métrique importante, susceptible de devenir le point d’attention principal lors de vos tests. Toutefois, pour les applications stratégiques, les tests de performances ne doivent pas s’arrêter à la mesure du comportement du serveur à l’état stable.

Envisagez d’inclure les scénarios suivants dans vos tests.

Les tests de « blackout », conçus pour déterminer le comportement de la base de données lors d’un redémarrage ou d’un incident. Le serveur Azure Database pour MySQL Flexible Server introduit des améliorations significatives en matière de temps de récupération après un crash, et les tests de redémarrage/crash sont essentiels pour comprendre comment Azure Database pour MySQL Flexible Server contribue à réduire le temps d'arrêt de votre application dans de telles situations.
Les tests de « brownout », conçus pour évaluer la rapidité avec laquelle une base de données atteint des niveaux de performances nominales après un redémarrage ou un incident. Les bases de données ont souvent besoin de temps pour obtenir des performances optimales, et le serveur flexible Azure Database pour MySQL introduit également des améliorations dans ce domaine.

En cas de problèmes de stabilité affectant votre base de données, toutes les informations collectées pendant les points de référence de performance vous aident à identifier les goulots d’étranglement ou à optimiser davantage l’application pour répondre aux besoins de la charge de travail.