Benchmarks sind eine der Aktivitäten, die Datenbankadministratoren durchführen. Sie führen sie aus, um zu sehen, wie sich Ihre Hardware verhält, Sie führen sie aus, um zu sehen, wie Ihre Anwendung und Datenbank unter Druck zusammenarbeiten. Sie führen sie in vielen verschiedenen Situationen aus. Lassen Sie uns ein wenig darüber sprechen, welchen Herausforderungen Sie sich stellen müssen und welche Probleme Sie vermeiden sollten.
Arten von Benchmarks
Jeder Benchmark ist anders. Sie dienen unterschiedlichen Zwecken und müssen berücksichtigt werden, wenn Sie planen, einen zu betreiben. Im Allgemeinen können Sie zwei Haupttypen von Benchmarks definieren:synthetische Benchmarks und, nennen wir es, „Real World“-Benchmarks.
Synthetische Benchmarks sind typischerweise Tools, die eine Art Arbeitslast simulieren. Es kann ein OLTP-Workload wie im Fall von Sysbench sein, es kann ein „Standard“-Benchmark wie in TPC-C oder TPC-H sein. Normalerweise ist die Idee, dass ein solcher Benchmark eine Art Workload simuliert, und es könnte nützlich sein, wenn Ihre reale Workload dem gleichen Muster folgen wird. Es kann auch verwendet werden, um zu bestimmen, wie Ihre Mischung aus Hardware- und Datenbankkonfiguration unter einer bestimmten Art von Arbeitslast zusammenarbeitet. Die Vorteile synthetischer Benchmarks liegen auf der Hand. Sie können sie überall ausführen, sie hängen nicht von einem bestimmten Setup oder Schemadesign ab. Nun, das tun sie, aber sie entwickeln Tools, um alles vom leeren Datenbankserver aus einzurichten. Der Hauptnachteil ist, dass dies nicht Ihre Arbeitsbelastung ist. Wenn Sie OLTP-Tests mit Sysbench durchführen, müssen Sie bedenken, dass Ihre Anwendung niemals Sysbench sein wird. Es kann auch eine OLTP-Arbeitslast ausführen, aber die Abfragemischung ist anders. Unter keinen Umständen wird Ihnen ein synthetischer Benchmark genau sagen, wie sich Ihre Anwendung auf einem bestimmten Hardware-/Konfigurationsmix verhalten wird.
Am anderen Ende des Spektrums haben wir Benchmarks aus der „realen Welt“. Was wir hier darunter verstehen, ist ein Benchmark, der einen Datensatz und Abfragen verwendet, die sich auf Ihre Anwendung beziehen. Es hat nicht immer einen vollständigen Datensatz und einen vollständigen Abfragemix. Möglicherweise möchten Sie sich auf einige Teile Ihrer Anwendung konzentrieren, aber die Hauptidee dahinter ist, dass Sie die genauen Wechselwirkungen zwischen Anwendung, Hardware und Datenbankkonfiguration verstehen möchten, entweder im Allgemeinen oder in einem bestimmten Aspekt.
Wie wir oben erwähnt haben, haben wir zwei verschiedene Arten von Benchmarks, aber sie haben dennoch einige gemeinsame Dinge, die Sie berücksichtigen müssen, wenn Sie versuchen, die Benchmarks auszuführen.
-
Entscheiden Sie, was Sie testen möchten
Zunächst einmal ist Benchmarking um des Benchmarking willen sinnlos. Es muss so gestaltet sein, dass es tatsächlich etwas bewirkt. Was möchten Sie aus dem Benchmark-Lauf herausholen? Möchten Sie die Abfragen optimieren? Möchten Sie die Konfiguration optimieren? Möchten Sie die Skalierbarkeit Ihres Stacks bewerten? Sie wollen Ihren Stack auf eine höhere Belastung vorbereiten? Möchten Sie eine generische Konfigurationsoptimierung für ein neues Projekt durchführen? Sie wollen die besten Einstellungen für Ihre Hardware ermitteln? Dies sind Beispiele für Ziele, die Sie möglicherweise erreichen möchten. Jede davon erfordert einen anderen Ansatz und ein anderes Benchmark-Setup.
-
Nehmen Sie jeweils eine Änderung vor
Was auch immer Sie testen und optimieren, es ist von größter Wichtigkeit, dass Sie nur eine Konfigurationsänderung auf einmal vornehmen. Das ist wirklich kritisch. Der Benchmark soll Ihnen eine Vorstellung von der Leistung geben. Abfragen pro Sekunde, Latenz, 99. Perzentil, das alles sagt Ihnen, wie schnell Sie die Abfragen ausführen können und wie stabil und vorhersehbar die Arbeitslast ist. Es ist leicht zu erkennen, ob die von Ihnen vorgenommene Änderung an Konfiguration, Hardware oder Abfragemix etwas ändert:Die Metriken aus dem Benchmark sehen anders aus. Die Sache ist, wenn Sie ein paar Änderungen gleichzeitig vornehmen, gibt es keine Möglichkeit zu sagen, welche für das Gesamtergebnis verantwortlich ist. Es kann sogar noch weiter gehen. Angenommen, Sie haben zwei Werte in der Datenbankkonfiguration geändert. Wert A und B. Die Gesamtverbesserung beträgt 20 %, was für nur eine Konfigurationsänderung ziemlich gut ist. Unter der Haube brachte die Änderung von Wert A jedoch eine Verbesserung von 30 %, während eine zusätzliche Änderung von Wert B sie auf 20 % zurücksetzte. Bei mehreren Änderungen gleichzeitig können Sie nur ihre gemeinsamen Auswirkungen beobachten. Dies ist nicht der Weg, um das Ergebnis jeder einzelnen von Ihnen vorgenommenen Änderung richtig zu bestimmen. Sicher, dies erhöht die Zeit, die Sie für die Ausführung des Benchmarks aufwenden, erheblich, aber so ist es.
-
Führen Sie mehrere Benchmark-Durchläufe durch
Computer sind komplexe Systeme für sich. Sie haben mehrere Komponenten, die miteinander interagieren:Speicher, CPU, Festplatte, Netzwerk. Dann fügen wir dieser Virtualisierung die Containerisierung hinzu. Dann Software - Betriebssystem, Anwendung, Datenbank. Schicht über Schicht über Schicht über Schicht von Elementen, die irgendwie interagieren. Es ist nicht einfach, sein Verhalten vorherzusagen. Nun, man kann sagen, dass es fast unmöglich ist, das Verhalten solch komplexer Systeme genau vorherzusagen. Aus diesem Grund reicht es nicht aus, einen Benchmark-Lauf durchzuführen, um die Schlussfolgerungen zu ziehen. Was ist, wenn, ohne dass Sie es wissen, ein Element, das nichts mit dem zu tun hat, was Sie testen möchten, die Gesamtleistung beeinflusst? Hohe Last auf einer anderen VM, die sich auf demselben Host befindet. Ein anderer Server streamt Backups über das Netzwerk. Dies kann die Leistung vorübergehend beeinträchtigen und die Benchmark-Ergebnisse verzerren. Wenn Sie nur einen Benchmark-Durchlauf durchführen, erhalten Sie am Ende falsche Ergebnisse. Aus diesem Grund besteht die beste Vorgehensweise darin, mehrere Durchgänge eines Benchmarks auszuführen und dann den langsamsten und den schnellsten zu entfernen und die anderen zu mitteln.
-
Ein Bild sagt mehr als tausend Worte
Nun, das ist so ziemlich eine sehr genaue Beschreibung von Benchmarking. Erstellen Sie nach Möglichkeit immer Grafiken. Verfolgen Sie idealerweise die Metriken während des Benchmarks so oft wie möglich. Eine Sekunde Auflösung sollte für die meisten Fälle ausreichen. Um zu vermeiden, Tausende von Wörtern zu schreiben, fügen wir dieses Beispiel hinzu. Was ist deiner Meinung nach sinnvoller? Dieser Satz von Benchmark-Ausgaben stellt die durchschnittlichen QPS für jeden von 10 Durchläufen dar, wobei jeder Durchlauf 600 Sekunden dauert
11650.52
11237.97
11550.16
11247.08
11177.78
11163.76
11131.47
11235.06
11235.59
11277.25
Oder diese Handlung:
Der durchschnittliche QPS-Wert beträgt 11.000, aber in Wirklichkeit ist die Leistung völlig übertrieben Platz, einschließlich Einbrüchen auf 0 Abfragen, die innerhalb einer Sekunde ausgeführt werden, und es ist definitiv etwas, an dem Sie arbeiten und das Sie auf den Produktionssystemen verbessern möchten.
-
Anfragen pro Sekunde sind nicht die wichtigste Metrik
Sie denken vielleicht, dass Abfragen pro Sekunde der heilige Gral der Leistung sind, da sie angibt, wie viele Abfragen eine Datenbank innerhalb einer Sekunde ausführen kann. Die Wahrheit ist, dass es nicht die wichtigste Metrik ist, besonders wenn wir über die durchschnittliche Ausgabe eines Benchmarks sprechen. QPS stellt den Durchsatz dar, ignoriert jedoch die Latenz. Sie können versuchen, eine große Anzahl von Abfragen zu pushen, warten dann aber darauf, dass sie Ergebnisse zurückgeben. Dies ist nicht das, was Benutzer von der Anwendung erwarten. Benutzer erwarten eine stabile Leistung. Es muss nicht blitzschnell sein, aber wenn eine Aktion eine Sekunde dauert, bis sie abgeschlossen ist, neigen wir dazu zu erwarten, dass die Ausführung dieser Aktion immer diese 1 Sekunde dauert. Wenn es aus irgendeinem Grund länger dauert, neigen Menschen dazu, ängstlich zu werden. Dies ist der Hauptgrund, warum wir die Latenz, insbesondere P99 (99. Perzentil) als zuverlässigere Metrik bevorzugen. Die Latenz sagt uns, wie lange die Anwendung auf das Ergebnis aus der Datenbank warten musste. P99 sagt uns, dass 99 % der Abfragen eine niedrigere Latenz haben als. Nehmen wir an, wir haben einen P99 von 100 ms, das bedeutet, dass 99 % der Abfragen Ergebnisse zurückgeben, die nicht langsamer als 100 ms sind. Wenn wir eine niedrige P99-Latenz sehen, bedeutet dies, dass fast alle Abfragen schnell zurückkehren und auf stabile, vorhersehbare Weise ausgeführt werden. Das wollen unsere Benutzer sehen.
-
Verstehen Sie, was passiert, bevor Sie Schlussfolgerungen ziehen
Letzter Punkt, den wir in diesem kurzen Blog haben, aber wir würden sagen, dass es der wichtigste ist. Sie werden während Benchmarks verschiedene seltsame und unerwartete Ergebnisse und Verhaltensweisen sehen. Schlimmer noch, Sie sehen möglicherweise ziemlich standardmäßige, sich wiederholende, aber immer noch fehlerhafte Ergebnisse. Die meisten von ihnen können auf das Verhalten der Datenbank oder Hardware zurückgeführt werden. Das ist wirklich entscheidend – bevor Sie das Ergebnis für selbstverständlich halten, sollten Sie in der Lage sein, das Verhalten zu erklären und zu beschreiben, was passiert ist. Wir wissen, dass es nicht einfach ist, und wir wissen, dass es wirklich datenbankspezifisches Wissen erfordert, insbesondere Wissen in Bezug auf die Interna der Datenbank. Wir wissen, dass sich die Leute in der realen Welt normalerweise nicht darum kümmern, sie wollen nur ein paar Ergebnisse erzielen. Die Sache ist die, insbesondere in Fällen, in denen Sie versuchen, die Leistung durch Konfiguration oder Hardware-Optimierungen zu verbessern. Wenn Sie verstehen, was unter der Haube passiert ist, können Sie die richtige Vorgehensweise für Ihre Abstimmung auswählen. Es ermöglicht auch zu sagen, ob der durchgeführte Benchmark einen Sinn haben könnte. Testen wir tatsächlich das richtige Element? Ein Beispiel wäre ein Test, der über das Netzwerk ausgeführt wird (weil Sie keine lokalen CPU-Kerne des Datenbankknotens für das Benchmark-Tool verwenden möchten). Es ist sehr wahrscheinlich, dass das Netzwerk selbst und die Softirq-CPU-Last der begrenzende Faktor sind, viel früher, als Sie „erwartete“ Engpässe wie CPU-Sättigung erreichen würden. Wenn Sie Ihre Umgebung und ihr Verhalten nicht kennen, messen Sie Ihre Netzwerkleistung, um große Datenmengen zu übertragen, nicht die CPU-Leistung.
Wie Sie sehen können, ist Benchmarking nicht die einfachste Sache, Sie müssen ein Bewusstsein dafür haben, was vor sich geht, Sie sollten einen richtigen Plan haben, was Sie tun werden und was willst du testen? Im nächsten Teil dieses Blogs werden wir einige der realen Testfälle durchgehen. Was kann schief gehen, auf welche Probleme werden wir stoßen und wie wir damit umgehen.
