Firebird Performance Newsletter: Ausgabe 1

Wir haben uns entschieden, einen mehr oder weniger regelmäßigen “Firebird Performance Newsletter” zu starten, der sich Leistungstests, Tipps, Tricks, Konfigurationsverbesserungen usw. widmet.

In der ersten Ausgabe haben wir Folgendes:

Firebird 4 vs. Firebird 3: Gute Nachrichten, alle zusammen!

Seit 2019, als wir die erste Sammlung von Ergebnissen aus dem einfachen INSERT/UPDATE/DELETE-Test veröffentlicht haben, haben uns viele Menschen Ergebnisse von ihren Firebird-Servern geschickt, und wir haben sie zur Tabelle und zum entsprechenden Diagramm hinzugefügt.

Der Test ist ein einfaches, aber leistungsfähiges Werkzeug, um die Leistung verschiedener Hardware- und Firebird-Konfigurationen zu messen und zu vergleichen, um schnell Hardware- oder Konfigurationsprobleme zu bestätigen oder zu widerlegen.

Kürzlich haben wir diesen Test verwendet, um die INSERT/UPDATE/DELETE-Leistung von Firebird 4.0 (Version 4.0.0.2394, einige Builds aus der Veröffentlichung) und 3.0 (Version 3.0.8.33426, Snapshot, Vorabversion des kommenden 3.0.8, die laut den Firebird-Autotests so stabil wie ein Minor-Release ist) zu vergleichen.

Die Testumgebung war ein Intel i3-10100F 3.60GHz mit SSD Samsung SSD 870QVO und RAM-Laufwerk (qSoft), mit verschiedenen RAM-Größen (16, 32, 64) und Page Buffers.

Unten ist das Diagramm, und hier ist die XLS-Tabelle mit den Ergebnissen.

Wie Sie sehen können, ist Firebird 4 unter denselben Bedingungen und mit derselben Konfiguration bei Schreiboperationen etwa 10% schneller als 3.0.8. Das ist definitiv eine gute Nachricht und ein weiteres Zeichen dafür, dass es an der Zeit ist, sich die kommende Version genauer anzusehen und mit den Vorbereitungen für die Migration zu beginnen.

Natürlich ist der beste Ansatz, denselben Test auf Ihrem eigenen Server auszuführen und die tatsächliche Verbesserung selbst zu sehen.

Siehe So geht’s »

Auswahl der besten AWS EC2-Instanz für maximale Firebird-Schreibleistung

Immer mehr Unternehmen denken über den “Umzug in die Cloud” nach, und Amazon Web Service Elastic Cloud ist eines der beliebtesten “Cloud-Ziele”.

AWS bietet jedoch viele verschiedene Instanztypen an - wie wählt man den besten aus? Natürlich, indem man Tests durchführt!

Wir haben die einfachen INSERT/UPDATE/DELETE-Tests für 20 Instanztypen durchgeführt und mehrere wirklich gute Optionen für Firebird gefunden.

Bitte beachten Sie - alle Preise in den Berechnungen und Diagrammen unten gelten für die Frankfurt-Region von AWS EC2, sie sind unverändert von aws.amazon.com übernommen, ohne Rabatte, können zusätzlichen Steuern unterliegen und sich im Laufe der Zeit ändern - bitte betrachten Sie die Preise unten nicht als endgültig oder als genauen Kaufleitfaden.

Hier ist das Gesamtdiagramm und die XLS-Tabelle mit den Ergebnissen:

Der Einfachheit halber haben wir die Spalte Operationen erstellt, die im Wesentlichen eine Summe aus Inserts+Updates+Deletes ist, und sie als vereinheitlichte Schreibleistungsmetrik verwendet:

Wie Sie sehen können, sind die folgenden 3 Instanztypen führend in der Leistung (aus Sicht der Firebird-Schreiboperationen):

Instanz	Stundensatz für Linux	Operationen/Sekunde

| z1d.xlarge | USD$0.45 | 45834 | | m5dn.2xlarge | USD$0.648 | 45198 | | m5d.2xlarge | USD$0.544 | 44150 |

Interessant ist, dass die Spitzenreiter nicht die teuersten Instanztypen sind! Natürlich müssen wir bedenken, dass der Test single-threaded ist (und nicht von der Anzahl der Kerne profitiert) und keine große Menge an RAM benötigt (da die Datenbank nur 3,6 GB groß ist), aber für Anwendungen, die schnell Spitzenlasten bei Schreiboperationen verarbeiten müssen, sehen diese Instanzen wirklich optimal aus.

Trotz der Tatsache, dass diese Instanztypen nicht die teuersten (unter den getesteten) sind, sind sie immer noch teuer genug, um zweimal über das Budget nachzudenken, und da einer der beworbenen Vorteile der Cloud Flexibilität ist, macht es Sinn, mit günstigeren VM-Instanztypen zu beginnen, die gut genug sein könnten, um unsere Firebird-Datenbank zu bedienen, oder?

Um die optimalen Kosten-/Leistungs-Instanztypen herauszufinden, haben wir eine weitere Spalte in unserer Tabelle erstellt: “Operationen pro 1 USD”.

Das bedeutet genau das, was es bedeutet - wie viele Schreiboperationen Sie für 1 USD kaufen können.

Die Formel lautet wie folgt:

Operationen_Pro_Sekunde * 3600 Sekunden pro Stunde / Preis pro Stunde

Wie Sie sehen können, sind die Spitzenreiter aus dieser Sicht andere:

Instanz	Linux-Stundenpreis	Operationen pro 1 USD	Operationen pro Sekunde
c5d.xlarge	USD$0,222	579062087	35709
c5ad.xlarge	USD$0,2	565024995	31390
m5dn.xlarge	USD$0,324	446037216	40143

Sehr interessant ist #3, m5dn.xlarge mit einer Spitzenleistung von ~40K pro Sekunde - es liegt ziemlich nahe am Leistungsspitzenreiter z1d.xlarge mit 45834 Operationen/Sekunde, ist aber deutlich günstiger.

Im Allgemeinen zeigt unsere Erfahrung mit AWS EC2, dass es eine stabile, ausgereifte Umgebung mit vielen guten Sicherheits-, Backup-, Hochverfügbarkeits- und anderen Funktionen ist, aber wie jede komplexe Plattform erfordert es Erfahrung (oder externes Fachwissen), um die richtige Wahl zu treffen und keine überhöhten Rechnungen für Anwendungen mit nicht fantastischer Last zu bezahlen.

Aktuelle Ergebnisse aus dem INSERT/UPDATE/DELETE-Test

Wie Sie sehen können, kann der einfache Test nicht nur als Vergleich zwischen Hardware und Firebirds nützlich sein, sondern auch ein paar Dollar sparen.

Wir haben ein Diagramm mit kürzlich gesammelten Ergebnissen und eine XLS-Tabelle zum Spielen veröffentlicht, sodass Sie es selbst hier überprüfen können.

Unten sind 3 offensichtliche Schlussfolgerungen:

NVME-Laufwerke rocken wirklich, also wenn Sie einen leistungsstarken Firebird-Server benötigen, kaufen Sie NVME für Datenbanken.
Die hohe CPU-Frequenz ist sehr wichtig für die hohe Leistung von Firebird-Datenbanken. Oft drängen Anbieter Sie dazu, Multi-Core-Prozessoren mit niedrigerer Frequenz (<3 GHz) zu kaufen, aber das ist möglicherweise nicht die beste Option für Firebird, und weniger Kerne mit höherer Frequenz können ein besseres Ergebnis liefern.
Wenn Ihr Datenbanklastprofil stark schreiborientiert ist, versuchen Sie, Page Buffers zu reduzieren: Experimentieren Sie mit DefaultDbCachePages wie 50K, 100K, 250K usw. Es wäre cool, wenn Sie die Ergebnisse mit uns teilen!

Sie können die Testergebnisse gerne untersuchen und Fragen stellen oder Vorschläge senden.

In der 2. Ausgabe zeigen wir, wie man mehrere SuperClassic-Instanzen konfiguriert, um eine Datenbank zu bedienen (unter anderem kann dies nützlich sein, um die Last auf mehrere Netzwerkports zu verteilen). Die Pläne für die nächsten Ausgaben sind groß: Konfigurationsfehler, Tests von verschlüsselten Datenbanken, erweiterter Vergleich der Firebird 4-Leistung mit Firebird 3, Optimierung von Indizes usw.

Wenn Sie interessiert sind und Benachrichtigungen über neue Ausgaben erhalten möchten, treten Sie unserem FirebirdSQL Telegram Channel bei.

Kontaktieren Sie uns

Bitte kontaktieren Sie uns bei Fragen und Anregungen: Alexey Kovyazin: [email protected].