Ce document décrit les recommandations pour exécuter des tests de performances sur AlloyDB Omni sur une VM. Dans ce document, nous partons du principe que vous connaissez PostgreSQL.
Lorsque vous effectuez un benchmark des performances, définissez ce que vous attendez du test avant de le commencer. Exemple :
- Quel est le débit maximal que le système peut atteindre ?
- Combien de temps dure une requête ou une charge de travail spécifique ?
- Comment les performances évoluent-elles à mesure que la quantité de données augmente ?
- Quelles sont les différences de performances entre deux systèmes différents ?
- De combien le moteur en colonnes réduit-il le temps de réponse de mes performances de requête ?
- Quelle charge une base de données peut-elle gérer avant que je doive envisager de passer à une machine plus puissante ?
Comprendre les objectifs de votre étude de performances vous indique le benchmark à exécuter, l'environnement requis et les métriques à collecter.
Reproductibilité
Pour tirer des conclusions des tests de performances, les résultats doivent être reproductibles. Si les résultats de vos tests présentent une grande variation, il sera difficile d'évaluer l'impact des modifications que vous avez apportées à l'application ou à la configuration du système. Exécuter des tests plusieurs fois ou sur une période plus longue pour obtenir plus de données peut contribuer à réduire la variation.
Dans l'idéal, les tests de performances doivent être exécutés sur des systèmes isolés des autres systèmes. Exécuter votre application dans un environnement où des systèmes externes peuvent affecter ses performances peut vous amener à tirer des conclusions incorrectes. L'isolation complète n'est souvent pas possible lorsque vous exécutez une analyse dans un environnement cloud multi-tenant. Vous devez donc vous attendre à une plus grande variabilité des résultats.
La répétabilité consiste en partie à s'assurer que la charge de travail de test reste la même entre les exécutions. Un certain niveau de hasard dans l'entrée d'un test est acceptable tant que ce hasard n'entraîne pas un comportement de l'application sensiblement différent. Si l'entrée client générée de manière aléatoire modifie la répartition des lectures et des écritures d'une exécution à l'autre, les performances varieront considérablement.
Taille de la base de données, mise en cache et modèles d'E/S
Assurez-vous que la quantité de données que vous utilisez pour les tests est représentative de votre application. Exécuter des tests avec une petite quantité de données alors que vous disposez de centaines de gigaoctets ou de téraoctets de données ne vous donnera probablement pas une représentation fidèle des performances de votre application. La taille de l'ensemble de données influence également les choix de l'optimiseur de requêtes. Les requêtes sur de petites tables de test peuvent utiliser des analyses de table qui offrent de mauvaises performances à plus grande échelle. Vous ne pourrez pas identifier les index manquants dans cette configuration.
Essayez de reproduire les modèles d'E/S de votre application. Le ratio de lectures par rapport aux écritures est important pour le profil de performances de votre application.
Durée de l'analyse comparative
Dans un système complexe, de nombreuses informations d'état sont maintenues pendant l'exécution du système: des connexions de base de données sont établies, des caches sont remplis, des processus et des threads sont créés. Au début d'un test de performances, l'initialisation de ces composants peut utiliser des ressources système et avoir un impact négatif sur les performances mesurées si l'exécution de la charge de travail est trop courte.
Nous vous recommandons d'exécuter les tests de performances pendant au moins 20 minutes afin de minimiser les effets de l'échauffement du système. Mesurez les performances pendant un état stable après le démarrage et suffisamment longtemps pour vous assurer que tous les aspects des opérations de base de données sont inclus. Par exemple, les points de contrôle de base de données sont une fonctionnalité essentielle des systèmes de base de données et peuvent avoir un impact significatif sur les performances. Exécuter un benchmark court qui se termine avant l'intervalle de point de contrôle masque ce facteur important du comportement de votre application.
Tests méthodiques
Lorsque vous ajustez les performances, ne modifiez qu'une seule variable à la fois. Si vous modifiez plusieurs variables entre les exécutions, vous ne pourrez pas identifier la variable qui a amélioré les performances. En effet, plusieurs modifications peuvent s'annuler les unes les autres, ce qui vous empêche de voir les avantages d'une modification appropriée. Si le serveur de base de données est surutilisé, essayez de passer à une machine avec plus de vCPU tout en maintenant la charge constante. Si le serveur de base de données est sous-utilisé, essayez d'augmenter la charge tout en maintenant la configuration du processeur constante.
Topologie et latence du réseau
La topologie réseau de votre système peut avoir une incidence sur les résultats des tests de performances. La latence entre les zones varie. Lorsque vous effectuez des tests de performances, assurez-vous que le client et le cluster de base de données se trouvent dans la même zone. Cela permet de réduire la latence réseau et d'obtenir les meilleures performances, en particulier pour les applications à haut débit et à transactions courtes, car la latence réseau peut représenter une part importante du temps de réponse global des transactions.
Lorsque vous comparez les performances de deux systèmes différents, assurez-vous que la topologie réseau est la même pour les deux. Notez que la variabilité de la latence réseau ne peut pas être complètement éliminée. Même au sein d'une même zone, il peut y avoir des différences de latence en raison des topologies réseau sous-jacentes.
Lorsque vous déployez votre application, vous pouvez mieux comprendre l'impact des latences interzones en considérant une application Web typique à fort volume. L'application dispose d'un équilibreur de charge qui envoie des requêtes à plusieurs serveurs Web déployés dans plusieurs zones pour assurer une haute disponibilité. Les latences peuvent varier en fonction du serveur Web qui traite une requête en raison des différences de latence entre les zones.
La figure suivante montre l'architecture type d'une application Web utilisant AlloyDB Omni. Les requêtes client sont gérées par un équilibreur de charge, qui transfère chaque requête vers l'un des nombreux serveurs Web. Les serveurs Web sont tous connectés à AlloyDB Omni. Certains serveurs se trouvent dans une zone différente de celle où AlloyDB Omni s'exécute et présentent des latences plus élevées lors de l'envoi de requêtes de base de données.
Surveillance des ressources
Pour optimiser les performances de votre système de base de données, vous devez surveiller l'utilisation des ressources du système de base de données et des systèmes clients qui l'utilisent. En surveillant les deux systèmes, vous pouvez vous assurer que les systèmes clients fournissent suffisamment de charge de travail pour obtenir des mesures significatives dans le système de base de données. Il est essentiel de surveiller l'utilisation des ressources du système que vous testez. Il est tout aussi important de surveiller l'utilisation des ressources des systèmes clients que vous utilisez pour générer la charge de travail. Par exemple, si vous souhaitez déterminer le nombre maximal de clients que votre système de base de données peut prendre en charge avant qu'il ne manque de ressources de processeur, vous aurez besoin de systèmes clients suffisants pour générer la charge de travail requise pour utiliser toutes les ressources de processeur du système de base de données. Vous ne pourrez pas exploiter le système de base de données suffisamment si les machines clientes générant de la charge ne disposent pas elles-mêmes de suffisamment de processeurs.
Tests d'évolutivité
Les tests d'évolutivité sont un autre aspect des tests de performances. L'évolutivité fait référence à la façon dont les métriques de performances changent à mesure qu'une caractéristique d'une charge de travail varie. Voici quelques exemples d'études d'évolutivité:
- Comment une augmentation du nombre de requêtes simultanées affecte-t-elle le débit et les temps de réponse ?
- Comment une augmentation de la taille de la base de données affecte-t-elle le débit et les temps de réponse ?
Les tests d'évolutivité consistent en plusieurs exécutions d'une charge de travail, où une seule dimension varie entre les exécutions, et une ou plusieurs métriques sont collectées et tracées. Ce type de test permet de prendre des décisions sur les goulots d'étranglement existants dans le système, la charge que le système peut gérer pour une configuration spécifique, la charge maximale qu'un système peut supporter et le comportement du système lorsque la charge augmente au-delà de ces niveaux.
Considérations concernant la taille de la machine
AlloyDB Omni introduit de nombreuses nouvelles fonctionnalités dans Postgres pour améliorer la fiabilité et la disponibilité de la base de données. La surveillance nécessaire à cette fin utilise des ressources sur la machine exécutant AlloyDB Omni. Les ressources de mémoire et de processeur sont limitées sur les machines de très petite taille. Par conséquent, pour les tests de référence, nous vous recommandons d'utiliser des machines de quatre vCPU minimum.