Das Firebird-Projekt freut sich, die allgemeine Verfügbarkeit von Firebird 5.0.1 bekannt zu geben – der neuesten Nebenversion der Firebird 5.0-Serie.
Diese Nebenversion bietet Fehlerbehebungen sowie einige Verbesserungen. Die vollständige Liste der Änderungen finden Sie in den Versionshinweisen.
Binär-Kits für Windows-, Linux-, MacOS- und Android-Plattformen stehen ab sofort zum Download zur Verfügung.
Firebird 5.0.1 verfügbar
Moderator: martin.koeditz
-
martin.koeditz
- Beiträge: 470
- Registriert: Sa 31. Mär 2018, 14:35
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Hm, so richtig der Knaller ist das nicht.
Gibts irgendwelche Performance-Vergleiche von 3.0 => 4.0 => 5.0?
IBExpert hatte da 2021 einen vergleich 3.0 zu 4.0 mit leichten Performanceeinbußen. Insbesonders eine größere Pagesize (32K) macht das Ganze langsamer.
Für ETL und Query-Abfragen mit Massendaten würde ich mir eher eine parallele Query-Engine wünschen, so dass die Abfrage selber viel schneller wird.
Auch hinsichtlich der Stabilität hätte ich da noch ein paar Wünsche.
Immer wieder kommt es vor, dass abgebrochene Verbindungen nicht rausgeschmissen werden und so die Satzversionen ansteigen.
Dies verlangsamt dann die Abfrage zusätzlich, da alte Satzversionen überlesen werden müssen. Das kann dann schon mal zur verzehnfachten (oder mehr) Abfragedauer führen.
Wir haben uns jetzt einen Watcher gebaut, der tote Verbindungen löscht, was dann zum korrigieren der Transaktions-ID's (oldest active) führt und Satzversionen verschhwinden.
Dies ist sicherlich auch dem TCP/IP geschuldet, da es kein echtes Polling zu geben scheint. TCPKEEPALIVE funktioniert da oft halt nicht.
Ich habe es auch schon erlebt, dass nach einem Save/Restore tote Verbindungen immer noch da sind.
Gibts irgendwelche Performance-Vergleiche von 3.0 => 4.0 => 5.0?
IBExpert hatte da 2021 einen vergleich 3.0 zu 4.0 mit leichten Performanceeinbußen. Insbesonders eine größere Pagesize (32K) macht das Ganze langsamer.
Für ETL und Query-Abfragen mit Massendaten würde ich mir eher eine parallele Query-Engine wünschen, so dass die Abfrage selber viel schneller wird.
Auch hinsichtlich der Stabilität hätte ich da noch ein paar Wünsche.
Immer wieder kommt es vor, dass abgebrochene Verbindungen nicht rausgeschmissen werden und so die Satzversionen ansteigen.
Dies verlangsamt dann die Abfrage zusätzlich, da alte Satzversionen überlesen werden müssen. Das kann dann schon mal zur verzehnfachten (oder mehr) Abfragedauer führen.
Wir haben uns jetzt einen Watcher gebaut, der tote Verbindungen löscht, was dann zum korrigieren der Transaktions-ID's (oldest active) führt und Satzversionen verschhwinden.
Dies ist sicherlich auch dem TCP/IP geschuldet, da es kein echtes Polling zu geben scheint. TCPKEEPALIVE funktioniert da oft halt nicht.
Ich habe es auch schon erlebt, dass nach einem Save/Restore tote Verbindungen immer noch da sind.
-
martin.koeditz
- Beiträge: 470
- Registriert: Sa 31. Mär 2018, 14:35
Gibt es eine Möglichkeit deine Erkenntnisse an die Entwickler weiterzugeben? Dann ist für die Zukunft sich noch was drin.
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Nö, dafür ist mir die Lust vergangen.
Meine kleinen Vorschläge beim .Net-FirebirdClient wurden ja auch nicht akzeptiert.
Die Änderung des Readers bringt z.T. erhebliche Vorteile, wenn nur kurze Resultsets mit vielen Feldern abgefragt werden, da intern für jedes Feld benötigte Attribute mit Einzelquery ergänzt werden, statt 1 Query für alle beteiligten Tabellen durchzuführen.
Da im Schnitt 1 Query ca. 10 Millisekunden braucht, kann man ja sehen, dass ein Result mit 1 Satz aber 100 Feldern dann mindestens 1 Sekunde braucht.
Klar kann man hier sagen, dass das ja nicht wehtut. Aber in Multiuserumgebungen oder Web-App's mit 1000den Abfragen / Minute kann man den Durchsatz erheblich steigern.
Und ggf. auf Webfarmen o.ä. verzichten, da 1 Server plötzlich genügt.
Ich habe die aktuelle Version 10 runtergeladen und meine Änderungen wieder bei mir eingebracht.
Dabei bin ich nebenbei noch auf das sog. ParameterCollection-Objekt gestoßen.
Beim Füllen von mehreren 1000 Parametern braucht der ziehmlich lange, da jeder neue Parameter erst mal mit Find über alle vorhandenen auf Eindeutigkeit geprüft wird und nach dem Add wird mit IndexOf der Index in der Liste ermittelt.
Das macht bei einem Bulkcopy für 13000 Parameter dann alleine schon 2 Sekunden.
Mit der Verwendung von Dictionary läuft das in unter 10 Millisekunden.
Insgesamt konnte ich da einen Breakeven bei ca. 2048 Parametern feststellen. Mit mehr Parametern wird es wieder langsamer, da das verpacken, senden, entpacken den Vorteil wieder wegnimmt.
Wenn hier im Kleinen schon nicht auf Performance geachtet wird, weiß ich nicht, wie das in der DB selber ist. Da gibts mit Sicherheit auch das Potential die eine oder andere Funktion zu optimieren.
Aber da bin ich inzwischen zu alt, mich da noch zu streiten.
Meine kleinen Vorschläge beim .Net-FirebirdClient wurden ja auch nicht akzeptiert.
Die Änderung des Readers bringt z.T. erhebliche Vorteile, wenn nur kurze Resultsets mit vielen Feldern abgefragt werden, da intern für jedes Feld benötigte Attribute mit Einzelquery ergänzt werden, statt 1 Query für alle beteiligten Tabellen durchzuführen.
Da im Schnitt 1 Query ca. 10 Millisekunden braucht, kann man ja sehen, dass ein Result mit 1 Satz aber 100 Feldern dann mindestens 1 Sekunde braucht.
Klar kann man hier sagen, dass das ja nicht wehtut. Aber in Multiuserumgebungen oder Web-App's mit 1000den Abfragen / Minute kann man den Durchsatz erheblich steigern.
Und ggf. auf Webfarmen o.ä. verzichten, da 1 Server plötzlich genügt.
Ich habe die aktuelle Version 10 runtergeladen und meine Änderungen wieder bei mir eingebracht.
Dabei bin ich nebenbei noch auf das sog. ParameterCollection-Objekt gestoßen.
Beim Füllen von mehreren 1000 Parametern braucht der ziehmlich lange, da jeder neue Parameter erst mal mit Find über alle vorhandenen auf Eindeutigkeit geprüft wird und nach dem Add wird mit IndexOf der Index in der Liste ermittelt.
Das macht bei einem Bulkcopy für 13000 Parameter dann alleine schon 2 Sekunden.
Mit der Verwendung von Dictionary läuft das in unter 10 Millisekunden.
Insgesamt konnte ich da einen Breakeven bei ca. 2048 Parametern feststellen. Mit mehr Parametern wird es wieder langsamer, da das verpacken, senden, entpacken den Vorteil wieder wegnimmt.
Wenn hier im Kleinen schon nicht auf Performance geachtet wird, weiß ich nicht, wie das in der DB selber ist. Da gibts mit Sicherheit auch das Potential die eine oder andere Funktion zu optimieren.
Aber da bin ich inzwischen zu alt, mich da noch zu streiten.
Die Versionen 3.0.12 und 4.0.5 sind inzwischen auch da:
https://firebirdsql.org/en/firebird-3-0/
https://firebirdsql.org/en/firebird-4-0/
https://firebirdsql.org/en/firebird-3-0/
https://firebirdsql.org/en/firebird-4-0/
--
Joachim
Joachim
Ja, angebnlich ist das Ganze gerade bei vielen paralleleln Connections viel schneller, bzw. bricht weniger ein:bfuerchau hat geschrieben: ↑Fr 2. Aug 2024, 16:02 Hm, so richtig der Knaller ist das nicht.
Gibts irgendwelche Performance-Vergleiche von 3.0 => 4.0 => 5.0?
IBExpert hatte da 2021 einen vergleich 3.0 zu 4.0 mit leichten Performanceeinbußen. Insbesonders eine größere Pagesize (32K) macht das Ganze langsamer.
https://ib-aid.com/download/docs/2024/F ... eTests.pdf
Edit: ich hab jetzt selbst mal den Test auf unserem DBServer laufen lassen.
CPU: AMD EPYC 9174F
RAM: 128Gb (getestet wurde aber mit 16K page size, 50K Buffer, also nicht viel)
Speicher 1: RAID10 aus 4 x Intel D3-S4620
Speicher2: Intel Optane P4800X 375Gb
FB 3.0.8 auf den RAID10:
Insert, Records/sec 23112
Update, Records/sec 13582
Delete, Records/sec 44115
FB 5.0.1 auf den RAID10:
Insert, Records/sec 29271
Update, Records/sec 16974
Delete, Records/sec 55258
FB 5.0.1 auf die Optane Server SSD:
Insert, Records/sec 29465
Update, Records/sec 17326
Delete, Records/sec 57003
Ausgeführt wurde der normale ib-aid test, nicht lokal, sondern vom anderen Server im gleichen Rack. Jeweils mit der Firebird3 isql Version. FB5 lief im legacy User Mode, ob das Ganze nativ noch besser ist muss ichs schauen.
Schon nett....
MfG Michael