In diesem Dokument werden Empfehlungen für die Ausführung von Leistungstests für AlloyDB Omni auf einer VM beschrieben. In diesem Dokument wird davon ausgegangen, dass Sie mit PostgreSQL vertraut sind.
Legen Sie vor Beginn des Leistungstests fest, was Sie aus dem Test lernen möchten. Beispiel:
- Was ist der maximale Durchsatz, den das System erreichen kann?
- Wie lange dauert eine bestimmte Abfrage oder Arbeitslast?
- Wie verändert sich die Leistung, wenn die Datenmenge zunimmt?
- Wie unterscheiden sich die Leistungen der beiden Systeme?
- Inwiefern reduziert die spaltenorientierte Engine die Antwortzeit meiner Abfrageleistung?
- Wie viel Last kann eine Datenbank bewältigen, bevor ich ein Upgrade auf einen leistungsstärkeren Computer in Betracht ziehen sollte?
Die Ziele Ihrer Leistungsstudie bestimmen, welchen Benchmark Sie ausführen, welche Umgebung erforderlich ist und welche Messwerte Sie erfassen müssen.
Wiederholbarkeit
Damit aus den Leistungstests Rückschlüsse gezogen werden können, müssen die Testergebnisse reproduzierbar sein. Wenn Ihre Testergebnisse stark variieren, ist es schwierig, die Auswirkungen der Änderungen an der Anwendung oder der Systemkonfiguration zu beurteilen. Wenn Sie Tests mehrmals oder über einen längeren Zeitraum ausführen, um mehr Daten zu erhalten, kann dies dazu beitragen, die Abweichung zu verringern.
Idealerweise sollten Leistungstests auf Systemen durchgeführt werden, die von anderen Systemen isoliert sind. Wenn Sie die Tests in einer Umgebung ausführen, in der externe Systeme die Leistung Ihrer Anwendung beeinträchtigen können, können Sie zu falschen Schlussfolgerungen gelangen. Eine vollständige Isolation ist bei der Ausführung in einer mehrmandantenfähigen Cloud-Umgebung oft nicht möglich. Daher sollten Sie mit einer größeren Variabilität der Ergebnisse rechnen.
Ein Teil der Wiederholbarkeit besteht darin, dafür zu sorgen, dass die Testarbeitslast zwischen den einzelnen Durchläufen gleich bleibt. Eine gewisse Zufälligkeit bei der Eingabe in einen Test ist akzeptabel, solange die Zufälligkeit nicht zu einem deutlich anderen Anwendungsverhalten führt. Wenn sich durch die zufällig generierte Clienteingabe die Mischung aus Lese- und Schreibvorgängen von Durchlauf zu Durchlauf ändert, schwankt die Leistung erheblich.
Datenbankgröße, Caching und I/O-Muster
Achten Sie darauf, dass die Menge der Daten, mit denen Sie testen, für Ihre Anwendung repräsentativ ist. Wenn Sie Tests mit einer kleinen Datenmenge ausführen, obwohl Sie Hunderte von Gigabyte oder Terabyte an Daten haben, erhalten Sie wahrscheinlich keine genaue Darstellung der Leistung Ihrer Anwendung. Die Größe des Datensatzes wirkt sich auch auf die Entscheidungen des Abfrageoptimierungstools aus. Bei Abfragen für kleine Testtabellen werden möglicherweise Tabellenscans verwendet, die bei größeren Skalen zu einer schlechten Leistung führen. In dieser Konfiguration werden keine fehlenden Indexe erkannt.
Achten Sie darauf, die E/A-Muster Ihrer Anwendung zu replizieren. Das Verhältnis von Lese- zu Schreibvorgängen ist wichtig für das Leistungsprofil Ihrer Anwendung.
Benchmark-Dauer
In einem komplexen System werden viele Statusinformationen bei der Ausführung des Systems verwaltet: Datenbankverbindungen werden hergestellt, Caches werden gefüllt, Prozesse und Threads werden gestartet. Zu Beginn eines Leistungstests kann die Initialisierung dieser Komponenten Systemressourcen beanspruchen und sich negativ auf die gemessene Leistung auswirken, wenn die Laufzeit der Arbeitslast zu kurz ist.
Wir empfehlen, Leistungstests mindestens 20 Minuten lang auszuführen, um die Auswirkungen des Aufwärmens des Systems zu minimieren. Messen Sie die Leistung nach dem Start in einem stabilen Zustand und so lange, dass alle Aspekte der Datenbankvorgänge berücksichtigt werden. Datenbank-Prüfpunkte sind beispielsweise eine wichtige Funktion von Datenbanksystemen und können sich erheblich auf die Leistung auswirken. Wenn Sie einen kurzen Benchmark ausführen, der vor dem Checkpoint-Intervall abgeschlossen ist, wird dieser wichtige Faktor im Verhalten Ihrer Anwendung ausgeblendet.
Methodische Tests
Ändern Sie bei der Leistungsoptimierung jeweils nur eine Variable. Wenn Sie zwischen den Durchläufen mehrere Variablen ändern, können Sie nicht feststellen, welche Variable die Leistung verbessert hat. Mehrere Änderungen können sich sogar gegenseitig aufheben, sodass Sie den Nutzen einer geeigneten Änderung nicht erkennen. Wenn der Datenbankserver überlastet ist, wechseln Sie zu einem Computer mit mehr vCPUs und halten Sie die Auslastung konstant. Wenn der Datenbankserver nicht ausreichend ausgelastet ist, versuchen Sie, die Auslastung zu erhöhen, während die CPU-Konfiguration konstant bleibt.
Netzwerktopologie und Latenzen
Die Netzwerktopologie Ihres Systems kann sich auf die Ergebnisse des Leistungstests auswirken. Die Latenz zwischen den Zonen unterscheidet sich. Wenn Sie Leistungstests durchführen, sollten Sie darauf achten, dass sich der Client und der Datenbankcluster in derselben Zone befinden. So wird die Netzwerklatenz minimiert und die beste Leistung erzielt – insbesondere bei Anwendungen mit hohem Durchsatz und kurzen Transaktionen, da die Netzwerklatenz einen großen Teil der gesamten Transaktionsantwortzeit ausmachen kann.
Achten Sie beim Vergleich der Leistung von zwei verschiedenen Systemen darauf, dass die Netzwerktopologie für beide Systeme identisch ist. Die Schwankungen der Netzwerklatenz können nicht vollständig beseitigt werden. Selbst innerhalb derselben Zone kann es aufgrund der zugrunde liegenden Netzwerktopologien zu Unterschieden bei der Latenz kommen.
Wenn Sie Ihre Anwendung bereitstellen, sollten Sie die Auswirkungen von zonenübergreifenden Latenzen besser verstehen. Dazu können Sie sich eine typische Webanwendung mit hohem Volumen ansehen. Die Anwendung hat einen Load Balancer, der Anfragen an mehrere Webserver sendet, die für eine hohe Verfügbarkeit in mehreren Zonen bereitgestellt werden. Die Latenzen können sich je nach Webserver, der eine Anfrage verarbeitet, aufgrund von zonenübergreifenden Latenzunterschieden unterscheiden.
Die folgende Abbildung zeigt die typische Architektur einer Webanwendung mit AlloyDB Omni. Clientanfragen werden von einem Load Balancer verarbeitet, der jede Anfrage an einen der vielen Webserver weiterleitet. Die Webserver sind alle mit AlloyDB Omni verbunden. Einige Server befinden sich in einer anderen Zone als AlloyDB Omni. Bei Datenbankanfragen treten dort höhere Latenzen auf.
Ressourcenmonitoring
Um die Leistung Ihres Datenbanksystems zu optimieren, müssen Sie die Ressourcennutzung sowohl des Datenbanksystems als auch der Clientsysteme, die das Datenbanksystem verwenden, im Blick behalten. Wenn Sie beide Systeme überwachen, können Sie dafür sorgen, dass die Clientsysteme eine ausreichende Arbeitslast bereitstellen, um aussagekräftige Messungen im Datenbanksystem zu erhalten. Es ist wichtig, die Ressourcennutzung des getesteten Systems zu überwachen. Ebenso wichtig ist es, die Ressourcennutzung der Clientsysteme zu überwachen, die Sie für die Arbeitslast verwenden. Wenn Sie beispielsweise die maximale Anzahl von Clients ermitteln möchten, die Ihr Datenbanksystem unterstützen kann, bevor die CPU-Ressourcen aufgebraucht sind, benötigen Sie genügend Clientsysteme, um die Arbeitslast zu generieren, die erforderlich ist, um alle CPU-Ressourcen im Datenbanksystem zu verbrauchen. Wenn die Clientcomputer, die die Last erzeugen, nicht über genügend CPU verfügen, können Sie das Datenbanksystem nicht ausreichend auslasten.
Skalierbarkeitstests
Skalierbarkeitstests sind ein weiterer Aspekt von Leistungstests. Die Skalierbarkeit bezieht sich darauf, wie sich Leistungsmesswerte ändern, wenn sich eine Eigenschaft einer Arbeitslast ändert. Beispiele für Skalierungsstudien:
- Wie wirken sich mehr gleichzeitige Anfragen auf den Durchsatz und die Antwortzeiten aus?
- Wie wirken sich eine Vergrößerung der Datenbankgröße auf den Durchsatz und die Antwortzeiten aus?
Skalierbarkeitstests bestehen aus mehreren Ausführungen einer Arbeitslast, bei denen eine einzelne Dimension zwischen den Ausführungen variiert und ein oder mehrere Messwerte erfasst und dargestellt werden. Anhand dieser Art von Tests können Sie Entscheidungen darüber treffen, welche Engpässe im System vorhanden sind, wie viel Last das System bei einer bestimmten Konfiguration bewältigen kann, welche maximale Last ein System unterstützen kann und wie sich das System verhält, wenn die Last über diese Werte hinaus ansteigt.
Überlegungen zur Maschinengröße
AlloyDB Omni bietet viele neue Funktionen für Postgres, um die Zuverlässigkeit und Verfügbarkeit der Datenbank zu verbessern. Das dazu erforderliche Monitoring beansprucht Ressourcen auf dem Computer, auf dem AlloyDB Omni ausgeführt wird. Bei sehr kleinen Maschinengrößen sind Arbeitsspeicher- und CPU-Ressourcen von vornherein begrenzt. Für Benchmarks empfehlen wir daher Maschinengrößen mit mindestens vier vCPUs.