Bewährte Methoden zum Benchmarking der Leistung von „Azure Database for MySQL – flexibler Server“

2025-06-24

Die Leistung ist ein wesentliches Qualitätsmerkmal jeder Anwendung. Daher ist es wichtig, eine klare Strategie für die Analyse und Bewertung der Leistung einer Datenbank bei der Verarbeitung der unterschiedlichen Workloadanforderungen einer Anwendung festzulegen.

Dieser Artikel enthält Überlegungen und bewährte Methoden zum Ausführen von Leistungs benchmarks für Azure Database for MySQL Flexible Server.

Leistungstests

Das synthetische Benchmarking der Leistung relationaler Datenbanksysteme mag auf den ersten Blick wie eine triviale Aufgabe erscheinen. Schließlich ist es relativ einfach, die Leistung einzelner Abfragen manuell zu bewerten und mit einem der verfügbaren Benchmarkingtools einfache synthetische Tests durchzuführen. Diese Testarten nehmen wenig Zeit in Anspruch und liefern schnell leicht verständliche Ergebnisse.

Das Benchmarking der Leistung von realen Produktionssystemen ist jedoch mit einem erheblichen Mehraufwand verbunden. Es ist nicht einfach, Tests zu entwerfen, zu implementieren und durchzuführen, die für Produktionsworkloads wirklich repräsentativ sind. Noch schwieriger ist es, Entscheidungen über Produktionsdatenstapel auf Grundlage der Ergebnisse einer Reihe von Benchmarks zu treffen, die in einer isolierten Umgebung durchgeführt wurden.

Methoden für Leistungstests

Synthetische Benchmarks

Synthetische Tests dienen dazu, ein Datenbanksystem mithilfe künstlicher Beispielworkloads auszulasten, die wiederholbare Ergebnisse in einer Datenbankumgebung simulieren. Auf diese Weise können Kunden mehrere Umgebungen miteinander vergleichen, um die geeignete Datenbankressource für ihre Produktionsbereitstellungen zu ermitteln.

Die Verwendung synthetischer Benchmarks bietet verschiedene Vorteile, Beispiel:

Sie sind vorhersehbar, wiederholbar und ermöglichen selektive Tests (z. B. reine Schreibtests, reine Lesetests, eine Kombination aus Schreib- und Lesetests und gezielte Tests für eine Tabelle).
Sie liefern Gesamtergebnisse, die mit einfachen Metriken dargestellt werden können (z. B. „Abfragen pro Sekunde“, „Transaktionen pro Sekunde“ usw.).
Für ihre Erstellung und Ausführung werden keine anwendungs- oder umgebungsspezifischen Kenntnisse benötigt.
Sie können schnell durchgeführt werden und erfordern nur wenig oder gar keine Vorbereitung. Es gibt jedoch auch einige Nachteile:
Künstliche Beispielworkloads sind nicht repräsentativ für den realen Anwendungsdatenverkehr.
Die Ergebnisse können nicht dazu herangezogen werden, die Leistung von Produktionsworkloads genau vorherzusagen.
Sie liefern möglicherweise keine produktspezifischen Leistungsmerkmale, wenn sie zum Testen verschiedener Datenbankprodukte verwendet werden.
Die Tests können leicht falsch durchgeführt werden und zu Ergebnissen führen, die noch weniger repräsentativ sind.

Synthetische Tests sind praktisch für einen schnellen Vergleich zwischen Produkten. Sie können auch dazu genutzt werden, Mechanismen für eine fortlaufende Leistungsüberwachung zu implementieren. Sie können beispielsweise jedes Wochenende eine Testsammlung ausführen, um die Basisleistung Ihres Datenbanksystems zu überprüfen, Anomalien zu erkennen und langfristige Leistungsmuster vorherzusagen (z. B. eine Verschlechterung der Abfragelatenz infolge des Datenwachstums).

Praxisnahe Benchmarks

Bei praxisnahen Tests werden für die Datenbank Beispielworkloads verwendet, die dem Produktionsdatenverkehr sehr ähnlich sind. Sie können dies direkt erreichen, indem Sie ein Protokoll der Produktionsabfragen wiedergeben und die Datenbankleistung messen. Sie können dies auch indirekt erreichen, indem Sie den Test auf Anwendungsebene durchführen und die Anwendungsleistung auf einem bestimmten Datenbankserver messen.

Die Verwendung von praxisnahen Benchmarks hat verschiedene Vorteile:

Sie bieten einen genauen Überblick über die Systemleistung unter realen Produktionsbedingungen.
Sie können anwendungs- oder datenbankspezifische Merkmale aufdecken, die bei vereinfachten synthetischen Tests nicht erkennbar wären.
Sie bieten Unterstützung bei der Kapazitätsplanung im Zusammenhang mit dem Anwendungswachstum.

Praxisnahe Benchmarks haben auch gewisse Nachteile:

Sie sind schwierig zu entwerfen und auszuführen.
Sie müssen gewartet werden, um ihre Relevanz zu gewährleisten, wenn sich die Anwendung weiterentwickelt.
Sie liefern Ergebnisse, die nur im Kontext einer bestimmten Anwendung von Bedeutung sind.

Wenn Sie sich auf eine weitreichende Änderung an Ihrer Umgebung vorbereiten, z. B. bei der Einführung eines neuen Datenbankprodukts, sollten Sie unbedingt Tests unter realen Bedingungen durchführen. In einer solchen Situation stellt ein umfassender Benchmarklauf mit der tatsächlichen Produktionsworkload eine wertvolle Hilfe dar. Er liefert nicht nur genaue und verlässliche Ergebnisse, sondern eliminiert auch die unbekannten Faktoren in Bezug auf Ihr System oder reduziert diese zumindest erheblich.

Auswählen der richtigen Testmethode

Die richtige Testmethode für Ihre Zwecke hängt ganz vom Ziel Ihrer Tests ab.

Für einen schnellen Vergleich verschiedener Datenbankprodukte anhand von künstlichen Beispieldaten und -workloads können Sie bedenkenlos ein vorhandenes Benchmarkprogramm verwenden, das Daten generiert und den Test für Sie durchführt.

Zur genauen Beurteilung der Leistung einer konkreten Anwendung, die Sie auf einem neuen Datenbankprodukt ausführen möchten, sollten Sie Benchmarktests unter realen Bedingungen durchführen. Jede Anwendung hat ihre eigenen Anforderungen und Leistungsmerkmale, und es wird empfohlen, dass Sie bei allen Leistungsbewertungen auch praxisnahe Benchmarktests durchführen.

Richtlinien zum Vorbereiten und Ausführen synthetischer und praxisnaher Benchmarks finden Sie in den folgenden Abschnitten weiter unten in diesem Artikel:

Vorbereiten und Ausführen synthetischer Tests
Vorbereiten und Ausführen praxisnaher Tests

Bewährte Methoden für Leistungstests

Serverspezifische Empfehlungen

Serverdimensionierung

Verwenden Sie beim Starten von Azure Database für MySQL Flexible Server-Instanzen zum Durchführen eines Benchmarkings eine Azure-Datenbank für die Instanzebene "MySQL Flexible Server", "SKU" und "Instanzanzahl", die Ihrer aktuellen Datenbankumgebung entsprechen.

Beispiel:

Wenn Ihr aktueller Server über acht CPU-Kerne und 64 GB Arbeitsspeicher verfügt, wählen Sie am besten eine Instanz mit der SKU „Standard_E8ds_v4“.
Wenn Ihre aktuelle Datenbankumgebung Read Replicas verwendet, verwenden Sie Azure Database für MySQL Flexible Server-Lesereplikate.

Abhängig von den Ergebnissen Ihrer Benchmarktests können Sie sich dazu entschließen, in der Produktion Instanzen unterschiedlicher Größe und Anzahl zu verwenden. Dennoch hat es sich bewährt, die anfänglichen Spezifikationen der Testinstanzen an Ihre aktuellen Serverspezifikationen anzugleichen, um einen präziseren Vergleich zu ermöglichen.

Serverkonfiguration

Wenn für die Anwendung oder den Benchmark bestimmte Datenbankfunktionen aktiviert sein müssen, passen Sie vor der Ausführung des Benchmarktests die Serverparameter entsprechend an. Beispielsweise müssen Sie eventuell:

Legen Sie eine andere als die standardmäßige Serverzeitzone fest.
Legen Sie einen benutzerdefinierten „max_connections“-Parameter fest, wenn der Standardwert nicht ausreicht.
Konfigurieren Sie den Threadpool, wenn Ihre Instanz des Azure-Datenbanksystems für MySQL Flexible Server Version 8.0 ausgeführt wird.
Aktivieren Sie „Protokolle für langsame Abfragen“ für eine Verwendung in der Produktion, um Abfragen mit Engpässen analysieren zu können.

Andere Parameter, z. B. diejenigen, die sich auf die Größe verschiedener Datenbankpuffer und Caches beziehen, sind bereits in Der Azure-Datenbank für MySQL Flexible Server vorkonfiguriert, und Sie können sie zunächst bei ihren Standardwerten festlegen lassen. Sie sollten nur dann Änderungen an den Serverparametern vornehmen, wenn Ihre Leistungsbenchmarks zeigen, dass eine bestimmte Änderung tatsächlich zu einer Leistungssteigerung führt.

Wenn Sie Tests durchführen, die Azure Database for MySQL Flexible Server mit anderen Datenbankprodukten vergleichen, sollten Sie unbedingt alle Funktionen aktivieren, die Sie in Ihrer Produktionsumgebung zu nutzen beabsichtigen, auch in Ihren Testdatenbanken. Wenn Sie beispielsweise in Ihrer Testumgebung weder zonenredundante Hochverfügbarkeit (High Availability, HA) noch Sicherungen und Lesereplikate aktivieren, spiegeln Ihre Ergebnisse die tatsächliche Leistung möglicherweise nicht genau wider.

Clientspezifische Empfehlungen

Alle Leistungsbenchmarks erfordern den Einsatz eines Clients. Daher sollten Sie unabhängig von der gewählten Methode für das Benchmarking die folgenden Empfehlungen für die Clientseite beachten.

Stellen Sie sicher, dass Clientinstanzen in demselben virtuellen Azure-Netzwerk (VNet) vorhanden sind wie die Azure-Datenbank für mySQL Flexible Server-Instanz, die Sie testen. Für latenzempfindliche Anwendungen empfiehlt es sich, die Clientinstanzen in derselben Verfügbarkeitszone zu platzieren wie den Datenbankserver.
Wenn erwartet wird, dass eine Produktionsanwendung auf mehreren Instanzen ausgeführt wird (z. B. eine App-Server-Flotte hinter einem Lastenausgleichsmodul), empfiehlt es sich, beim Durchführen des Benchmarks mehrere Clientinstanzen zu verwenden.
Stellen Sie sicher, dass alle Clientinstanzen über ausreichende Compute-, Speicher-, E/A- und Netzwerkkapazität verfügen, um den Benchmark zu bewältigen. Anders ausgedrückt: Die Clients müssen in der Lage sein, Anfragen schneller zu generieren, als die Datenbank-Engine sie verarbeiten kann. Alle Betriebssysteme bieten Diagnosetools (z. B. „top“, „htop“, „dstat“ oder „iostat“ unter Linux), mit denen Sie die Ressourcenauslastung auf Clientinstanzen diagnostizieren können. Es wird dringend empfohlen, diese Tools zu nutzen und sicherzustellen, dass alle Clientinstanzen stets über freie CPU-, Speicher-, Netzwerk- und E/A-Kapazität verfügen, während der Benchmark ausgeführt wird.

Selbst bei einer großen SKU ist eine einzelne Clientinstanz möglicherweise nicht immer in der Lage, Anforderungen schnell genug zu generieren, um die Datenbank zu sättigen. Je nach Testkonfiguration kann Azure-Datenbank für MySQL Flexible Server Hunderte von Tausenden von Lese-/Schreibanforderungen pro Sekunde verarbeiten, was möglicherweise mehr als ein einzelner Client aufnehmen kann. Um bei umfangreichen Leistungstests Konflikte auf der Clientseite zu vermeiden, ist es daher gängige Praxis, einen Benchmark über mehrere Clientinstanzen parallel auszuführen.

Wichtig

Wenn Sie Ihre Anwendung mit einem Skript zum Generieren von Datenverkehr oder einem Drittanbietertool (z. B. Apache Benchmark, Apache JMeter oder Siege) testen, sollten Sie auch die Instanz, auf der das Tool ausgeführt wird, anhand der zuvor genannten Empfehlungen bewerten.

Vorbereiten und Ausführen synthetischer Tests

Synthetische Benchmarkingtools wie sysbench sind einfach zu installieren und auszuführen, erfordern in der Regel jedoch ein gewisses Maß an Konfiguration und Optimierung, bevor ein bestimmter Benchmark optimale Ergebnisse erzielen kann.

Tabellenanzahl und -größe

Die Anzahl und Größe der vor dem Benchmarking erstellten Tabellen sollten hoch sein. So dürften beispielsweise Tests, die für eine einzelne Tabelle mit 100.000 Zeilen durchgeführt werden, kaum brauchbare Ergebnisse liefern, da ein solches Dataset wahrscheinlich kleiner ist als jede echte Datenbank. Zum Vergleich: Ein Benchmark unter Verwendung mehrerer Tabellen (z. B. 10–25) mit jeweils 5 Millionen Zeilen wäre eine realistischere Darstellung einer Echtzeitworkload.

Testmodus

Bei den meisten Benchmarktools (einschließlich des beliebten sysbench) können Sie die Art der Workload definieren, die Sie für den Server ausführen möchten. Beispielsweise kann das Tool Folgendes generieren:

Reine Leseabfragen mit identischer Syntax, aber unterschiedlichen Parametern
Reine Leseabfragen verschiedener Typen (Punktauswahl, Bereichsauswahl, Auswahl mit Sortierungen usw.)
Reine Schreibanweisungen, die einzelne Zeilen oder Zeilenbereiche ändern
Eine Kombination aus Lese-/Schreibanweisungen.

Sie können Workloads mit reinen Lese- oder Schreibzugriffen verwenden, wenn Sie die Leistung und Skalierbarkeit der Datenbank in diesen speziellen Szenarien testen möchten. Ein repräsentativer Benchmark sollte jedoch in der Regel einen guten Mix aus Lese- und Schreibanweisungen enthalten, da dies die Art von Workload ist, die die meisten OLTP-Datenbanken verarbeiten müssen.

Parallelitätsgrad

Der Parallelitätsgrad gibt die Anzahl von Threads an, die gleichzeitig Vorgänge in der Datenbank ausführen. Die meisten Benchmarktools verwenden standardmäßig einen einzelnen Thread, was für echte Datenbankumgebungen nicht repräsentativ ist, da Datenbanken selten nur von einem einzigen Client genutzt werden.

Gehen Sie wie folgt vor, um die theoretische Spitzenleistung einer Datenbank zu testen:

Führen Sie mehrere Tests durch, und verwenden Sie für jeden Test eine andere Anzahl von Threads. Beginnen Sie z. B. mit 32 Threads, und erhöhen Sie die Anzahl der Threads für jeden weiteren Test (64, 128, 256 usw.).
Erhöhen Sie die Anzahl der Threads weiter, bis sich die Leistung der Datenbank stabilisiert hat – dies ist die theoretische Spitzenleistung.
Wenn Sie feststellen, dass die Leistung der Datenbank bei einem bestimmten Parallelitätsgrad nicht mehr zunimmt, können Sie die Anzahl der Threads trotzdem noch ein paar Mal erhöhen. So lässt sich ermitteln, ob die Leistung stabil bleibt oder zu sinken beginnt. Weitere Informationen finden Sie im Blogbeitrag Benchmarking von Azure Database for MySQL – Flexible Server mit Sysbench.

Vorbereiten und Ausführen praxisnaher Tests

Jede Anwendung ist in Bezug auf Datenmerkmale und Leistungsanforderungen einzigartig. Daher ist es relativ schwierig, eine einzige, allgemeingültige Liste von Schritten für die Vorbereitung und Durchführung eines repräsentativen, praxisnahen Benchmarks in einer beliebigen Datenbankumgebung aufzustellen.

Die in diesem Abschnitt vorgestellten Anregungen sollen Ihnen die Durchführung von Leistungstests etwas erleichtern.

Vorbereiten von Testdaten

Bevor Sie Leistungs benchmarks für Azure Database for MySQL Flexible Server durchführen, stellen Sie sicher, dass der Server mit einer repräsentativen Stichprobe Ihres Produktionsdatensatzes gefüllt wird.

Verwenden Sie, wann immer möglich, eine vollständige Kopie des Produktionsdatasets. Falls dies nicht möglich ist, können Sie anhand der folgenden Vorschläge bestimmen, welche Daten Sie auf jeden Fall einbeziehen sollten und welche Daten Sie weglassen können.

Der Testserver muss alle Objekte (d. h. Schemas, Tabellen, Funktionen und Prozeduren) enthalten, die direkt für den Benchmark verwendet werden. Jede Tabelle sollte vollständig aufgefüllt sein, d. h. sie sollte alle Zeilen enthalten, die sie in der Produktion enthält. Wenn die Tabellen nicht vollständig aufgefüllt sind (wenn sie z. B. nur eine kleine Stichprobe des Rowsets enthalten), sind die Benchmarkergebnisse nicht repräsentativ.
Schließen Sie Tabellen aus, die von Produktionsanwendungen verwendet werden, aber nicht Teil des fortlaufenden operativen Datenverkehrs sind. Ein Beispiel: Wenn eine Datenbank sowohl operative Livedaten als auch historische Daten enthält, die für Analysen verwendet werden, werden die historischen Daten möglicherweise nicht zur Durchführung von Benchmarks benötigt.
Füllen Sie alle Tabellen, die Sie auf den Testserver kopieren, mit echten Produktionsdaten und nicht mit künstlichen, programmgesteuert generierten Stichproben auf.

Entwerfen von Anwendungsbenchmarks

Das allgemeine Verfahren zur Durchführung von Anwendungsbenchmarks ist folgendes:

Erstellen Sie eine Azure-Datenbank für mySQL Flexible Server-Instanz, und füllen Sie sie mit einer Kopie Ihrer Produktionsdaten auf.
Stellen Sie eine Kopie der Anwendung in Azure bereit.
Konfigurieren Sie die Anwendung für die Verwendung der Azure-Datenbank für mySQL Flexible Server-Instanz.
Führen Sie Auslastungstests für die Anwendung aus, und bewerten Sie die Ergebnisse.

Dieser Ansatz ist vor allem dann sinnvoll, wenn Sie problemlos eine Kopie Ihrer Anwendung in Azure bereitstellen können. Er ermöglicht es Ihnen, die Leistungsbeurteilung so gründlich und genau wie möglich durchzuführen. Dennoch gibt es einige Empfehlungen, die Sie beachten sollten.

Das zum Generieren des Anwendungsdatenverkehrs verwendete Tool muss in der Lage sein, eine Kombination aus Anforderungen zu erzeugen, die für Ihre Produktionsworkload repräsentativ ist. Greifen Sie beim Testen beispielsweise nicht wiederholt auf dieselbe Anwendungs-URL zu, da dies vermutlich nicht der Nutzung der Anwendung durch Ihre Kundinnen und Kunden in der Praxis entspricht.
Der Pool mit Client- und Anwendungsinstanzen muss leistungsfähig genug sein, um Anforderungen zu generieren, zu bearbeiten und Antworten von der Datenbank zu empfangen, ohne dass es zu Engpässen kommt.
Der Parallelitätsgrad (die Anzahl der vom Benchmarktool erzeugten parallelen Anforderungen) sollte dem erwarteten maximalen Parallelitätsgrad entsprechen, der in Ihrer Anwendung beobachtet wird, oder diesen leicht übersteigen.

Entwerfen von Datenbankbenchmarks

Wenn Sie nicht einfach eine Kopie Ihrer Anwendung in Azure bereitstellen können, müssen Sie den Benchmark durchführen, indem Sie SQL-Anweisungen direkt für die Datenbank ausführen. Nutzen Sie dazu die folgende allgemeine Vorgehensweise:

Identifizieren Sie die SQL-Anweisungen, die am häufigsten in Ihrer Produktionsworkload vorkommen.
Bereiten Sie auf Grundlage der im ersten Schritt gesammelten Informationen eine umfangreiche Stichprobe mit SQL-Anweisungen zum Testen vor.
Erstellen Sie eine Azure-Datenbank für mySQL Flexible Server-Knoten, und füllen Sie ihn mit einer Kopie Ihrer Produktionsdaten auf.
Starten Sie Azure-VM-Client-Instanzen in Azure.
Führen Sie auf den virtuellen Computern das SQL-Workload-Beispiel für Ihre Azure-Datenbank für MySQL Flexible Server-Instanz aus, und bewerten Sie die Ergebnisse.

Es gibt zwei grundlegende Ansätze für das Generieren der Testnutzdaten (SQL-Anweisungsbeispiele):

Beobachten/erfassen Sie den SQL-Datenverkehr in Ihrer aktuellen Datenbank, und erstellen Sie dann basierend auf diesen Beobachtungen SQL-Stichproben. Einzelheiten dazu, wie man Abfrageaufkommen mithilfe einer Kombination aus Überwachungsprotokollen und Protokollierung langsamer Abfragen in Azure Datenbank für MySQL Flexible Server aufzeichnet.
Verwenden Sie tatsächliche Abfrageprotokolle als Nutzdaten. Drittanbietertools wie Percona Playback können Multithreading-Workloads auf der Grundlage von MySQL-Protokollen zu langsamen Abfragen erzeugen.

Wenn Sie die SQL-Stichprobe manuell erstellen möchten, achten Sie darauf, dass sie Folgendes enthält:

Eine ausreichend große Anzahl eindeutiger Anweisungen

Beispiel: Wenn Sie feststellen, dass die Produktionsworkload 15 Hauptanweisungstypen verwendet, reicht es nicht aus, wenn die Stichprobe insgesamt 15 Anweisungen (eine pro Typ) enthält. Bei einer so kleinen Stichprobe würde die Datenbank die erforderlichen Daten problemlos im Speicher zwischenspeichern, wodurch der Benchmark nicht repräsentativ wäre. Stellen Sie stattdessen eine umfangreiche Stichprobe für jeden Anweisungstyp bereit, und beachten Sie die folgenden zusätzlichen Empfehlungen.
Anweisungen verschiedener Typen im richtigen Verhältnis.

Beispiel: Wenn Sie feststellen, dass Ihre Produktionsworkload 12 Anweisungstypen verwendet, ist es wahrscheinlich, dass einige Anweisungstypen häufiger vorkommen als andere. Ihre Stichprobe sollte dieses Verhältnis widerspiegeln: Wenn Abfrage A in der Produktionsworkload 10-mal häufiger vorkommt als Abfrage B, sollte sie auch 10-mal häufiger in Ihrer Stichprobe vorkommen.
Abfrageparameter, die realitätsnah randomisiert sind

Wenn Sie die zuvor genannten Empfehlungen befolgt haben und Ihr Abfragebeispiel Gruppen von Abfragen desselben Typs/derselben Syntax enthält, sollten die Parameter dieser Abfragen randomisiert werden. Wenn die Stichprobe eine Million Abfragen desselben Typs enthält und diese alle identisch sind (einschließlich der Parameter in WHERE-Bedingungen), werden die erforderlichen Daten leicht im Datenbankspeicher zwischengespeichert, wodurch der Benchmark nicht repräsentativ ist.
Anweisungsausführungsreihenfolge, die realitätsnah randomisiert ist.

Wenn Sie die vorherigen Empfehlungen befolgen und Ihre Testnutzdaten viele Abfragen unterschiedlicher Typen enthalten, sollten Sie diese Abfragen in einer realistischen Reihenfolge ausführen. Die Stichprobe kann zum Beispiel 10 Millionen SELECT- und 1 Million UPDATE-Anweisungen enthalten. In einem solchen Fall stellt die Ausführung aller SELECT- vor allen UPDATE-Anweisungen nicht die beste Wahl dar, da Ihre Anwendung Abfragen in der Praxis vermutlich nicht auf diese Weise ausführt. Wahrscheinlicher ist, dass die Anwendung abwechselnd SELECT- und UPDATE-Anweisungen ausführt, und Ihr Test sollte dies nach Möglichkeit simulieren.

Wenn die Stichprobe mit Abfragen fertig ist, führen Sie sie mit einem MySQL-Befehlszeilenclient oder einem Tool wie mysqlslapv für den Server aus.

Ausführen von Tests

Unabhängig davon, ob Sie einen synthetischen Benchmark oder einen praxisnahen Leistungstest für eine Anwendung durchführen, sollten Sie einige Faustregeln beachten, um repräsentative Ergebnisse zu erzielen.

Ausführen von Tests für mehrere Instanztypen

Angenommen, Sie möchten Benchmarks mit einem Server des Typs „db.r3.2xlarge“ durchführen und stellen fest, dass die Anwendungs-/Abfrageleistung bereits Ihren Anforderungen entspricht. Es wird empfohlen, Tests sowohl mit kleineren als auch mit größeren Instanzen durchzuführen, was zwei Vorteile bietet:

Tests mit kleineren Instanztypen können dennoch gute Leistungsergebnisse liefern und Möglichkeiten zur Kosteneinsparung aufzeigen.
Tests mit größeren Instanztypen können Anregungen oder Erkenntnisse im Hinblick auf zukünftige Skalierungsoptionen liefern.

Messen der dauerhaften und der Spitzenleistung

Die von Ihnen gewählte Teststrategie sollte Ihnen Aufschluss darüber geben, ob die Datenbank angemessene Ergebnisse liefert:

Dauerhafte Leistung: Liefert das System bei normaler Arbeitslast die erwartete Leistung, wenn der Benutzerdatenverkehr reibungslos und innerhalb der erwarteten Grenzen verläuft?
Spitzenleistung: Ist die Reaktionsfähigkeit der Anwendung bei Datenverkehrsspitzen gewährleistet?

Berücksichtigen Sie die folgenden Richtlinien:

Stellen Sie sicher, dass die Testläufe lang genug sind, um die Leistung der Datenbank in einem stabilen Zustand zu beurteilen. Beispielsweise liefert ein komplexer Test, der nur 10 Minuten dauert, vermutlich ungenaue Ergebnisse, da die Caches und Puffer der Datenbank in so kurzer Zeit möglicherweise nicht aufgewärmt werden können.
Benchmarks können wesentlich aussagekräftiger und informativer sein, wenn die Arbeitslast während des Tests variiert. Wenn Ihre Anwendung z. B. üblicherweise Datenverkehr von 64 Clients gleichzeitig empfängt, starten Sie den Benchmark mit 64 Clients. Fügen Sie dann während des laufenden Tests 64 zusätzliche Clients hinzu, um festzustellen, wie sich der Server bei einer simulierten Datenverkehrsspitze verhält.

Aufnahme von Blackout-/Brownout-Tests in das Benchmarkverfahren

Die dauerhafte Serverleistung ist eine besonders wichtige Kennzahl, auf die Sie sich bei Ihren Tests wahrscheinlich am ehesten konzentrieren. Bei unternehmenskritischen Anwendungen sollten Leistungstests jedoch nicht bei der Messung des Serververhaltens im stabilen Zustand enden.

Erwägen Sie, die folgenden Szenarien in Ihre Tests einzubeziehen.

Mit einem Blackout-Test können Sie feststellen, wie sich die Datenbank bei einem Neustart oder einem Absturz verhält. „Azure Database for MySQL – flexibler Server“ führt erhebliche Verbesserungen bei den Wiederherstellungszeiten nach einem Systemabsturz ein. Neustart-/Absturztests sind wichtig, um zu verstehen, wie „Azure Database for MySQL – flexibler Server“ dazu beiträgt, die Ausfallzeiten Ihrer Anwendung in solchen Szenarien zu reduzieren.
Mit einem Brownout-Test können Sie feststellen, wie schnell eine Datenbank nach einem Neustart oder einem Absturz wieder ihre Nennleistung erreicht. Datenbanken benötigen oft Zeit, um eine optimale Leistung zu erzielen, und Azure Database für MySQL Flexible Server führt auch Verbesserungen in diesem Bereich ein.

Im Fall von Stabilitätsproblemen, die sich auf Ihre Datenbank auswirken, können Sie mithilfe der bei den Leistungsbenchmarks gesammelten Informationen Engpässe identifizieren oder die Anwendung weiter optimieren, um den Anforderungen der Workload gerecht zu werden.