Lorsque vous comparez les 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 ?
- Comment les performances de deux systèmes différents se comparent-elles ?
- Dans quelle mesure le moteur en colonnes réduit-il le temps de réponse des requêtes ?
- 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 des performances vous permet de déterminer 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 à la configuration de l'application ou du système. Pour réduire le montant de la variation, vous pouvez effectuer des tests plusieurs fois ou sur des périodes plus longues afin de fournir plus de données.
Dans l'idéal, les tests de performances doivent être exécutés sur des systèmes isolés des autres systèmes. L'exécution dans un environnement où des systèmes externes peuvent affecter les performances de votre application peut vous amener à tirer des conclusions incorrectes. Il est souvent impossible d'obtenir une isolation complète lorsque vous exécutez des tests dans un environnement cloud multitenant. Vous devez donc vous attendre à une plus grande variabilité des résultats.
Pour garantir la répétabilité, il faut s'assurer que la charge de travail de test reste la même entre les exécutions. Une certaine part d'aléatoire dans l'entrée d'un test est acceptable tant que cela n'entraîne pas un comportement de l'application significativement différent. Si l'entrée client générée de manière aléatoire modifie le mélange de lectures et d'é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 avec laquelle vous effectuez les tests est représentative de votre application. Si vous exécutez des tests avec une petite quantité de données alors que vous disposez de centaines de gigaoctets ou de téraoctets de données, vous n'obtiendrez 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 n'identifierez pas les index manquants dans cette configuration.
Essayez de reproduire les modèles d'E/S de votre application. Le ratio entre les lectures et les é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 conservées lors de 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 générés. Au début d'un test de performances, l'initialisation de ces composants peut consommer des ressources système et nuire aux performances mesurées si la durée d'exécution de la charge de travail est trop courte.
Nous vous recommandons d'exécuter des tests de performances pendant au moins 20 minutes pour 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. L'exécution d'un benchmark court qui se termine avant l'intervalle de point de contrôle masque ce facteur important dans le 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 celle qui a amélioré les performances. En effet, plusieurs modifications peuvent se compenser mutuellement, ce qui vous empêche de constater 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 processeurs virtuels tout en conservant la charge constante. Si le serveur de base de données est sous-utilisé, essayez d'augmenter la charge tout en conservant la configuration du processeur.
Topologie et latences 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 avec un débit élevé et des 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 du réseau est la même pour les deux systèmes. Notez que la variabilité de la latence du 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 de réseau sous-jacentes.
Lorsque vous déployez votre application, vous pouvez mieux comprendre l'impact des latences entre zones en considérant une application Web typique à volume élevé. 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 illustre l'architecture type d'une application Web utilisant AlloyDB Omni. Les requêtes des clients sont traitées par un équilibreur de charge, qui transfère chaque requête à 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 est exécuté et rencontreront 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 de manquer de ressources de processeur, vous aurez besoin de systèmes clients suffisants pour générer la charge de travail nécessaire à l'utilisation de toutes les ressources de processeur du système de base de données. Vous ne pourrez pas solliciter suffisamment le système de base de données si les machines clientes qui génèrent la charge ne disposent pas d'un processeur suffisant.
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 lorsqu'une caractéristique d'une charge de travail varie. Voici quelques exemples d'études de scalabilité :
- Comment une augmentation du nombre de requêtes simultanées modifie-t-elle le débit et les temps de réponse ?
- Comment l'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 où une ou plusieurs métriques sont collectées et représentées sous forme de graphique. Ce type de test permet de prendre des décisions concernant les goulots d'étranglement du système, la charge que le système peut gérer avec une configuration spécifique, la charge maximale qu'un système peut supporter et le comportement du système lorsque la charge dépasse ces niveaux.
Remarques sur 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 opération utilise des ressources sur la machine exécutant AlloyDB Omni. Les ressources de mémoire et de processeur sont limitées sur les très petites machines. Par conséquent, pour les tests comparatifs, nous vous recommandons d'utiliser des machines avec au moins quatre processeurs virtuels.