Lorsque vous effectuez un benchmark de performances, définissez ce que vous attendez du test avant de le débuter. Exemple :
- Quel est le débit maximal que le système peut atteindre ?
- Combien de temps prend l'exécution d'une requête ou d'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 les performances de mes requêtes en termes de temps de réponse ?
- 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 permet de déterminer le benchmark à exécuter, l'environnement requis et les métriques à collecter.
Reproductibilité
Pour qu'il soit possible de 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 volume de variation, vous pouvez effectuer les tests plusieurs fois (ou pendant des périodes plus longues) afin d'obtenir 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 mutualisé. Vous devez donc vous attendre à une plus grande variabilité des résultats.
Pour garantir la répétabilité, il faut également 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 qu'elle 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 mix 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 du benchmark
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. Les performances mesurées peuvent être impacté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 du "préchauffage" du système. Mesurez les performances lorsque le système a atteint 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. Ils 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 entraîné l'amélioration des 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 gardant la charge constante. Si le serveur de base de données est sous-utilisé, essayez d'augmenter la charge tout en conservant la configuration de processeur constante.
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, du fait que 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 prenant en compte 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 à des fins de 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'exécution 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 d'un nombre suffisant de systèmes clients 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'une quantité suffisante de ressources de processeur.
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 d'évolutivité :
- 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 aide à 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 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. Les capacités de surveillance nécessaires à cette opération utilisent 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 benchmarks, nous vous recommandons d'utiliser des machines comptant au moins quatre processeurs virtuels (vCPU).