Legen Sie vor Beginn des Benchmarking 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 ändert sich die Leistung, wenn die Datenmenge zunimmt?
- Wie schneidet die Leistung von zwei verschiedenen Systemen im Vergleich ab?
- Um wie viel reduziert die spaltenbasierte Engine die Reaktionszeit meiner Abfrageleistung?
- Wie viel Last kann eine Datenbank verarbeiten, bevor ich ein Upgrade auf eine leistungsstärkere Maschine in Betracht ziehen sollte?
Wenn Sie die Ziele Ihrer Leistungsstudie kennen, können Sie besser entscheiden, welcher Benchmark ausgeführt werden soll, welche Umgebung erforderlich ist und welche Messwerte Sie erfassen müssen.
Wiederholbarkeit
Um Schlussfolgerungen aus Leistungstests zu ziehen, müssen die Testergebnisse wiederholbar sein. Wenn Ihre Testergebnisse stark variieren, ist es schwierig, die Auswirkungen von Änderungen zu bewerten, die Sie an der Anwendung oder der Systemkonfiguration vorgenommen haben. Wenn Sie Tests mehrmals oder über einen längeren Zeitraum ausführen, um mehr Daten zu erhalten, können Sie die Abweichung verringern.
Idealerweise sollten Leistungstests auf Systemen ausgeführt werden, die von anderen Systemen isoliert sind. Wenn Sie in einer Umgebung arbeiten, in der externe Systeme die Leistung Ihrer Anwendung beeinträchtigen können, können Sie falsche Schlussfolgerungen ziehen. Eine vollständige Isolation ist in einer Cloud-Umgebung mit mehreren Mandanten oft nicht möglich. Daher ist mit einer größeren Variabilität der Ergebnisse zu rechnen.
Ein Teil der Wiederholbarkeit besteht darin, sicherzustellen, dass die Testarbeitslast zwischen den Ausführungen gleich bleibt. Eine gewisse Zufälligkeit bei der Eingabe in einen Test ist akzeptabel, solange sie nicht zu einem deutlich anderen Verhalten der Anwendung führt. Wenn sich die zufällig generierte Clienteingabe von Ausführung zu Ausführung ändert, variiert die Leistung erheblich.
Datenbankgröße, Caching und E/A-Muster
Achten Sie darauf, dass die Menge der Daten, mit denen Sie testen, repräsentativ für Ihre Anwendung ist. Wenn Sie Tests mit einer kleinen Datenmenge ausführen, obwohl Sie Hunderte von Gigabyte oder Terabyte an Daten haben, wird die Leistung Ihrer Anwendung wahrscheinlich nicht realistisch dargestellt. Die Größe des Datasets beeinflusst auch die Entscheidungen des Abfrageoptimierers. Bei Abfragen für kleine Testtabellen werden möglicherweise Tabellenscans verwendet, die bei größeren Datenmengen eine schlechte Leistung erbringen. Außerdem werden in dieser Konfiguration keine fehlenden Indexe erkannt.
Versuchen Sie, die E/A-Muster Ihrer Anwendung zu reproduzieren. Das Verhältnis von Lese- zu Schreibvorgängen ist wichtig für das Leistungsprofil Ihrer Anwendung.
Dauer des Benchmarks
In einem komplexen System werden viele Statusinformationen während 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 die gemessene Leistung beeinträchtigen, 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 im stabilen Zustand nach dem Start und lange genug, um sicherzustellen, dass alle Aspekte der Datenbankvorgänge berücksichtigt werden. Datenbank-Checkpoints sind beispielsweise eine wichtige Funktion von Datenbanksystemen und können erhebliche Auswirkungen auf die Leistung haben. Wenn Sie einen kurzen Benchmark ausführen, der vor dem Checkpoint-Intervall abgeschlossen ist, wird dieser wichtige Faktor im Verhalten Ihrer Anwendung nicht berücksichtigt.
Methodisches Testen
Ändern Sie bei der Leistungsoptimierung jeweils nur eine Variable. Wenn Sie zwischen den Ausführungen 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 Vorteil einer geeigneten Änderung nicht sehen. Wenn der Datenbankserver überlastet ist, versuchen Sie, zu einer Maschine mit mehr vCPUs zu wechseln und die Last konstant zu halten. Wenn der Datenbankserver unterlastet ist, versuchen Sie, die Last zu erhöhen und die CPU-Konfiguration konstant zu halten.
Netzwerktopologie und Latenzen
Die Netzwerktopologie Ihres Systems kann sich auf die Ergebnisse von Leistungstests auswirken. Die Latenz zwischen Zonen ist unterschiedlich. Wenn Sie Leistungstests durchführen, sollten Sie darauf achten, dass sich der Client und der Datenbankcluster in derselben Zone befinden. So minimieren Sie die Netzwerklatenz und erzielen die beste Leistung. Das gilt insbesondere für Anwendungen mit hohem Durchsatz und kurzen Transaktionen, da die Netzwerklatenz einen großen Teil der Reaktionszeit der Transaktion ausmachen kann.
Wenn Sie die Leistung von zwei verschiedenen Systemen vergleichen, muss die Netzwerktopologie für beide Systeme gleich sein. Die Variabilität der Netzwerklatenz lässt sich nicht vollständig beseitigen. Auch innerhalb derselben Zone kann es aufgrund der zugrunde liegenden Netzwerktopologien zu Unterschieden bei der Latenz kommen.
Wenn Sie Ihre Anwendung bereitstellen, möchten Sie möglicherweise die Auswirkungen von zonenübergreifenden Latenzen besser verstehen. Betrachten Sie dazu eine typische Webanwendung mit hohem Volumen. Die Anwendung hat einen Load-Balancer, der Anfragen an mehrere Webserver sendet, die in mehreren Zonen bereitgestellt werden, um eine hohe Verfügbarkeit zu gewährleisten. Die Latenzen können je nachdem, welcher Webserver eine Anfrage verarbeitet, aufgrund von Unterschieden bei der zonenübergreifenden Latenz variieren.
Die folgende Abbildung zeigt die typische Architektur einer Webanwendung, die AlloyDB Omni verwendet. Clientanfragen werden von einem Load-Balancer verarbeitet, der jede Anfrage an einen von vielen Webservern weiterleitet. Die Webserver sind alle mit AlloyDB Omni verbunden. Einige Server befinden sich in einer anderen Zone als AlloyDB Omni und haben bei Datenbankanfragen höhere Latenzen.
Ressourcenmonitoring
Um die Leistung Ihres Datenbanksystems zu optimieren, müssen Sie die Ressourcennutzung sowohl des Datenbanksystems als auch der Clientsysteme überwachen, die das Datenbanksystem verwenden. Wenn Sie beide Systeme überwachen, können Sie sicherstellen, dass die Clientsysteme genügend Arbeitslast bereitstellen, um aussagekräftige Messungen im Datenbanksystem zu erhalten. Die Überwachung der Ressourcennutzung des Systems, das Sie testen, ist entscheidend. Ebenso wichtig ist die Überwachung der Ressourcennutzung der Clientsysteme, die Sie zum Erzeugen der Arbeitslast verwenden. Wenn Sie beispielsweise die maximale Anzahl von Clients ermitteln möchten, die Ihr Datenbanksystem unterstützen kann, bevor die CPU-Ressourcen erschöpft sind, benötigen Sie genügend Clientsysteme, um die Arbeitslast zu erzeugen, die erforderlich ist, um alle CPU-Ressourcen im Datenbanksystem zu nutzen. Sie können das Datenbanksystem nicht ausreichend belasten, wenn die Clientmaschinen, die die Last erzeugen, selbst nicht genügend CPU-Ressourcen haben.
Skalierbarkeitstests
Skalierbarkeitstests sind ein weiterer Aspekt von Leistungstests. Skalierbarkeit bezieht sich darauf, wie sich Leistungsmesswerte ändern, wenn eine Eigenschaft einer Arbeitslast variiert. Beispiele für Skalierbarkeitsstudien:
- Wie ändert sich der Durchsatz und die Reaktionszeit bei einer Erhöhung der Anzahl gleichzeitiger Anfragen?
- Wie ändert sich der Durchsatz und die Reaktionszeit bei einer Erhöhung der Datenbankgröße?
Skalierbarkeitstests bestehen aus mehreren Ausführungen einer Arbeitslast, bei der eine einzelne Dimension zwischen den Ausführungen variiert wird. Dabei werden ein oder mehrere Messwerte erfasst und grafisch dargestellt. Diese Art von Tests liefert Informationen zu Engpässen im System, zur Last, die das System bei einer bestimmten Konfiguration verarbeiten kann, zur maximalen Last, die ein System unterstützen kann, und zum Verhalten des Systems, wenn die Last über diese Werte hinaus ansteigt.
Überlegungen zur Maschinengröße
AlloyDB Omni bietet viele neue Funktionen für PostgreSQL, um die Zuverlässigkeit und Verfügbarkeit der Datenbank zu verbessern. Für die dafür erforderliche Überwachung werden Ressourcen auf der Maschine verwendet, auf der AlloyDB Omni ausgeführt wird. Bei sehr kleinen Maschinengrößen sind die Arbeitsspeicher- und CPU-Ressourcen von Anfang an begrenzt. Für Benchmarking empfehlen wir daher Maschinengrößen mit mindestens vier vCPUs.