Legen Sie vor Beginn des Tests fest, was Sie daraus lernen möchten. Beispiel:
- Was ist der maximale Durchsatz, den das System erreichen kann?
- Wie lange dauert eine bestimmte Anfrage oder ein bestimmter Workload?
- Wie ändert sich die Leistung, wenn die Datenmenge zunimmt?
- Wie unterscheidet sich die Leistung zweier verschiedener Systeme?
- Wie stark wird die Antwortzeit meiner Abfrageleistung durch die spaltenorientierte Engine verkürzt?
- Wie viel Last kann eine Datenbank verarbeiten, bevor ich ein Upgrade auf einen leistungsstärkeren Computer in Betracht ziehen sollte?
Wenn Sie die Ziele Ihrer Leistungsstudie kennen, wissen Sie, welchen Benchmark Sie ausführen müssen, welche Umgebung erforderlich ist und welche Messwerte Sie erfassen müssen.
Wiederholbarkeit
Damit aus Leistungstests Schlussfolgerungen gezogen werden können, müssen die Testergebnisse wiederholbar sein. Wenn die Testergebnisse stark variieren, ist es schwierig, die Auswirkungen von Änderungen an der Anwendung oder der Systemkonfiguration zu bewerten. Wenn Sie Tests mehrmals oder über einen längeren Zeitraum durchführen, um mehr Daten zu erhalten, kann die Abweichung verringert werden.
Leistungstests sollten idealerweise auf Systemen ausgeführt werden, die von anderen Systemen isoliert sind. Wenn Sie Ihre Anwendung in einer Umgebung ausführen, in der externe Systeme die Leistung Ihrer Anwendung beeinträchtigen können, kann dies zu falschen Schlussfolgerungen führen. In einer Cloud-Umgebung mit mehreren Mandanten ist eine vollständige Isolation oft nicht möglich. Daher ist mit einer größeren Variabilität der Ergebnisse zu rechnen.
Ein wichtiger Aspekt der Wiederholbarkeit ist, dass die Testarbeitslast zwischen den Ausführungen gleich bleibt. Eine gewisse Zufälligkeit bei der Eingabe für einen Test ist akzeptabel, solange sie nicht zu einem deutlich anderen Verhalten der Anwendung führt. Wenn sich durch zufällig generierte Client-Eingaben das Verhältnis von Lese- und Schreibvorgängen von Lauf zu Lauf ä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 richtig dargestellt. Die Größe des Datasets beeinflusst auch die Entscheidungen des Abfrageoptimierungstools. Bei Abfragen für kleine Testtabellen werden möglicherweise Tabellenscans verwendet, die bei größeren Datenmengen zu einer schlechten Leistung führen. 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.
Benchmark-Dauer
In einem komplexen System werden während der Ausführung des Systems viele Statusinformationen verwaltet: Datenbankverbindungen werden hergestellt, Caches werden gefüllt, Prozesse und Threads werden gestartet. Zu Beginn eines Leistungstests kann die Initialisierung dieser Komponenten Systemressourcen in Anspruch nehmen 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 während eines stabilen Zustands nach dem Start und lange genug, um sicherzustellen, dass alle Aspekte der Datenbankvorgänge berücksichtigt werden. Datenbank-Checkpoints sind beispielsweise ein wichtiges Feature von Datenbanksystemen und können sich erheblich auf die Leistung auswirken. Wenn Sie einen kurzen Benchmark ausführen, der vor dem Checkpoint-Intervall abgeschlossen wird, wird dieser wichtige Faktor im Verhalten Ihrer Anwendung ausgeblendet.
Methodisches Testen
Ändern Sie jeweils nur eine Variable, wenn Sie die Leistung optimieren. Wenn Sie mehrere Variablen zwischen den Läufen ä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 einem Computer mit mehr vCPUs zu wechseln, während die Last konstant bleibt. Wenn der Datenbankserver nicht ausgelastet ist, versuchen Sie, die Last 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 Zonen variiert. Bei Leistungstests wird die Netzwerklatenz minimiert und die beste Leistung erzielt, wenn sich der Client und das Datenbankcluster in derselben Zone befinden. Das gilt insbesondere für 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 zweier verschiedener Systeme darauf, dass die Netzwerktopologie für beide Systeme identisch ist. Die Variabilität der Netzwerklatenz kann nicht vollständig eliminiert werden. Selbst innerhalb derselben Zone kann es aufgrund der zugrunde liegenden Netzwerktopologien zu Unterschieden bei der Latenz kommen.
Beim Bereitstellen Ihrer Anwendung sollten Sie die Auswirkungen von zonenübergreifenden Latenzen anhand einer typischen Webanwendung mit hohem Volumen besser nachvollziehen. Die Anwendung hat einen Load Balancer, der Anfragen zur Hochverfügbarkeit an mehrere Webserver sendet, die in mehreren Zonen bereitgestellt werden. Die Latenzen können je nach Webserver, der eine Anfrage verarbeitet, aufgrund von zonenübergreifenden Latenzunterschieden 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 weisen bei Datenbankanfragen höhere Latenzen auf.
Ressourcenmonitoring
Um die Leistung Ihres Datenbanksystems zu optimieren, müssen Sie die Ressourcennutzung des Datenbanksystems und der Clientsysteme, die das Datenbanksystem verwenden, im Blick behalten. Wenn Sie beide Systeme im Blick behalten, können Sie dafür sorgen, dass die Clientsysteme genügend Arbeitslast bereitstellen, um aussagekräftige Messungen im Datenbanksystem zu erhalten. Es ist wichtig, die Ressourcennutzung des Systems, das Sie testen, im Blick zu behalten. Ebenso wichtig ist es, die Ressourcennutzung der Clientsysteme zu überwachen, mit denen Sie die Arbeitslast ausführen. 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 generieren, die erforderlich ist, um alle CPU-Ressourcen im Datenbanksystem zu nutzen. Wenn die Clientcomputer, die die Last generieren, nicht über genügend CPU verfügen, können Sie das Datenbanksystem nicht ausreichend belasten.
Skalierbarkeitstests
Skalierbarkeitstests sind ein weiterer Aspekt von Leistungstests. Skalierbarkeit bezieht sich darauf, wie sich Leistungsmesswerte ändern, wenn sich eine Eigenschaft einer Arbeitslast ändert. Beispiele für Skalierbarkeitsstudien:
- Wie wirkt sich eine Erhöhung der Anzahl gleichzeitiger Anfragen auf Durchsatz und Reaktionszeiten aus?
- Wie wirkt sich eine größere Datenbank auf den Durchsatz und die Reaktionszeiten aus?
Skalierbarkeitstests bestehen aus mehreren Ausführungen einer Arbeitslast, bei denen eine einzelne Dimension zwischen den Ausführungen variiert wird und ein oder mehrere Messwerte erfasst und dargestellt werden. Diese Art von Tests liefert Informationen darüber, 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. Die dafür erforderliche Überwachung beansprucht Ressourcen auf dem Computer, auf dem AlloyDB Omni ausgeführt wird. Bei sehr kleinen Maschinengrößen sind die Arbeitsspeicher- und CPU-Ressourcen von vornherein begrenzt. Für Benchmarking empfehlen wir daher, Maschinengrößen mit mindestens vier vCPUs zu verwenden.